Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)

[Matt Palmer <mpalmer () hezmatt org>]

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