On Mon, Jun 15, 2009 at 11:26 PM, Mike Wilson
<mikewse@...> wrote:
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.
Totally.
There was a security report some time ago that gave DWR lots of gold stars for CSRF protection and dinged Dojo. I thought that it was quite unfair to ding Dojo since they were only client side, and CSRF protection required complex client-server interaction.
The point of this is partly to solve the impending HttpOnly problem with DWR, but also to be a wider standard that everyone can bit-by-bit start to employ. If Dojo/jQuery start to add those headers, then generic servers can add in checks. So it would be good to have a solution that doesn't involve server sent entropy.
Joe.
