nanog mailing list archives
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
From: Matt Palmer <mpalmer () hezmatt org>
Date: Sat, 19 Jan 2013 14:52:28 +1100
On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:
On 17 January 2013 23:38, Matt Palmer <mpalmer () 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.
But if you don't want to store this secret key anywhere in the server, you can relie in security by obscurity, and generate it by a predictible algorithm, like md5( year + "_SALT_" + id_user +day_of_year). A attacker can figure out the algorithm, or it can be leaked, but if your site is small, and don't protect anything important, it will stop the 100% of the attackers anyway.
It doesn't even have to be broken -- it isn't going to take long for an attacker to notice that your "security token" doesn't change every time, and work out how often it does change, then plan their attacks around that. If you make the change frequency greater, then you're increasing the risk of rejecting valid submissions when the token rolls over. To avoid that, you need to start checking against a set of token values, which need to be recalculated every time or stored somewhere for use later. It's not particularly surprising that people go instead for the quick and easy "drop in a cookie and compare the value with the form submission" option. And by the way, I wouldn't be so confident about being small avoiding the miscreants. Those "Pay us $1k or we'll DoS you off the Internet and send you broke" scam merchants are going after smaller and smaller targets, as there's more of them and they're completely unable to afford other effective forms of protection. - Matt
Current thread:
- Re: ripe/ncc likes cookies, (continued)
- Re: ripe/ncc likes cookies Randy Bush (Jan 12)
- Re: ripe/ncc likes cookies Grant Ridder (Jan 12)
- Re: ripe/ncc likes cookies Randy Bush (Jan 12)
- RE: ripe/ncc likes cookies Keith Medcalf (Jan 12)
- Re: ripe/ncc likes cookies Owen DeLong (Jan 14)
- Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Shrdlu (Jan 16)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) john (Jan 17)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Matt Palmer (Jan 17)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) . (Jan 18)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Matt Palmer (Jan 19)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) George Herbert (Jan 19)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) Matt Palmer (Jan 20)
- Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...) George Herbert (Jan 20)