[Owasp-csrfguard] How CSRFGuard Protects Ajax

eric sheridan eric.sheridan at owasp.org
Wed Dec 29 11:05:09 EST 2010

I'm not crazy about the double-cookie submit strategy, actually. While
there is technical merit to this approach, it increases the general
risk of session identifier exposure. Placing the session identifier in
HTML via JavaScript or server-side processing will cause problems with
the HTTPOnly defense. Implementations will either have to a) insert
the identifier via JavaScript (i.e. disable HTTPOnly) or b) insert the
identifier when the HTML is produced (i.e. negate the benefit of
HTTPOnly). An XSS vulnerability in either condition would greatly
increase the risk of session hijacking. Let's not put all of our eggs
in one basket - the session identifier already plays enough of a role.
I would encourage the use of a separate token with a more targeted
responsibility - i.e. prevent CSRF. If that token is exposed in some
way, then we are subject to CSRF attacks which is likely less of a
risk to an application than a successful session hijacking attack. The
strategy works, but the exposure of the 'token' has a greater negative
impact in double-submit cookie as opposed to the CSRFGuard-style
synchronizer token pattern.


On Thu, Dec 23, 2010 at 2:35 PM, Jim Manico <jim.manico at owasp.org> wrote:
> I think the choice to add entropy to Ajax requests, and not depend on same-origin was a very wise idea. Nice, Eric!
> Eric, may I ask what your opinion is on the double-cookie submit CSRF defense method? I've heard a lot of chatter about it lately...
> -Jim Manico
> http://manico.net
> On Dec 23, 2010, at 7:44 AM, eric sheridan <eric.sheridan at owasp.org> wrote:
>> OWASP CSRFGuard List,
>> There have been several discussions on web application security
>> mailing lists and blogs about the best strategy to protect Ajax
>> interfaces from Cross-Site Request Forgery (CSRF) attacks. Most of
>> these discussions center around verification of the X-Requested-With
>> header or adoption and subsequent verification of the Origin header. I
>> thought now would be a good time to talk about how OWASP CSRFGuard v3
>> protects Ajax interfaces from CSRF attacks. CSRFGuard makes use of
>> JavaScript function hijacking to inject custom headers into valid
>> requests sent by the XMLHttpRequest object. These headers include
>> X-Requested-With and a custom header name value pair containing the
>> per-session CSRF prevention token. More technical details of that
>> strategy including a discussion of the Origin header can be found at
>> http://ericsheridan.blogspot.com/2010/12/how-csrfguard-protects-ajax.html.
>> My big driver here is to encourage people to review, test, and provide
>> feedback on the current status of OWASP CSRFGuard v3. Please let me
>> know what you think!
>> -Eric
>> _______________________________________________
>> Owasp-csrfguard mailing list
>> Owasp-csrfguard at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-csrfguard

More information about the Owasp-csrfguard mailing list