Joe wrote:
On Mon, Jun 15, 2009 at 4:49 PM, Mike Wilson
<mikewse@...>
wrote:
...
I was thinking that maybe this cookie could also be used for
your suggestion on the new CSRF protection mechanism, but I made some tests
and at least IE (surprise) seems to do no locking and be very
liberal about changing cookie values under your feet when you work with
the same cookie in multiple windows. So this would need some more
work.
Absolutely.
I revised the scheme to avoid this:
1: Read the
anti-csrf-cookie
2: If empty, generate a new random password and place in
the cookie
3: Place the value in an anti-csrf header
4: Post
request
I don't think the value needs to change, just to be
unpredictable.
I
don't come to think of any reasons why the cookie would need to change, so this
sounds pretty good! If we want to seed it with an unpredictable value we could
use the server-sent "entropy" cookie from my other post. Or maybe
Math.random() is good enough.
Btw,
if allowing iframe requests then we would need to allow for the secret token to
travel inside the request body instead, to be compared with
anti-csrf-cookie on arrival.
Best
regards
Mike
