Anti CSRF IDs (Was: File upload progress)

[Joe Walker-3]

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've spoken to John Resig and Dylan about it, and they're both of the opinion that if we could make the alg. small enough then they might consider using it by default. Otherwise it would need to be a plugin.

But I've not had time to hack on it much recently.

Joe.

[mikewse]

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

[Joe Walker-3]

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.

[mikewse]

If you think up the way you want to generate the random password we can probably implement this between the two of us. Anyway I guess it should be a session cookie so we at least change the password between browser restarts.

 

Best regards

Mike

---

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: den 16 juni 2009 09:53
To: users@...
Subject: Re: [dwr-user] Anti CSRF IDs (Was: File upload progress)

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.