On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote: > On Jan 18, 2013, at 7:52 PM, Matt Palmer <mpal...@hezmatt.org> wrote: > > On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote: > >> On 17 January 2013 23:38, Matt Palmer <mpal...@hezmatt.org> wrote: > >> .. > >>> By the way, if anyone *does* know of a good and reliable way to prevent > >>> CSRF > >>> without the need for any cookies or persistent server-side session state, > >>> I'd love to know how. Ten minutes with Google hasn't provided any useful > >>> information. > >> > >> I think many people create <forms> with a secret code that is > >> different and hopefully can't be predicted by the attackers. > >> > >> <form method="post"> > >> <input type="hidden" name="id_user" value="33"> > >> <input type="hidden" name="action" value="delete_user"> > >> <input type="hidden" name="secret" > >> value="5ebe2294ecd0e0f08eab7690d2a6ee69"> > >> <input type="submit" value="Delete user"> > >> </from> > >> > >> The easy way to do this is to generate secret from the md5 if time in > >> miliseconds + a salt string, and store the secret generated > >> serverside. > > > > Storing any state server-side is a really bad idea for scalability and > > reliability. > > ? > > Doing that - into a user state DB of sone sort, either external or in > middleware, is routine...
It may be routine, but it is an additional point of failure, and it is also an additional scaling bottleneck. If all you ever run are tiny sites with little chance of ever seeing big loads, sure, stick it in a DB somewhere. But if you ever think (or even hope) that your site will take off one day, it pays to think about these things and reduce the number of fires to put out by one. - Matt
