[WEB SECURITY] How are you tackling CSRF?
rohirp92 at yahoo.com
Tue Apr 26 07:24:33 EDT 2011
Yes, I do not intend to say that CSRF fix would provide XSS protection. I was
trying to say that if you have extremely strong CSRF protection on all pages
post-login, it would become *difficult* for an attacker to exploit XSS. This is
of-course no relaxation for implementing strong XSS fix.
From: Sebastian Schinzel <ssc at seecurity.org>
To: Rohit Pitke <rohirp92 at yahoo.com>
Cc: web security <websecurity at webappsec.org>
Sent: Tue, April 26, 2011 1:06:20 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
On Apr 25, 2011, at 10:06 AM, Rohit Pitke wrote:
> You are basically assuming that there is XSS on some of the requests. If there
>is no XSS, even if you keep a value of your CSRF token same as cookies, it wont
> Also, if we correctly implement CSRF on each and every page (including GET),
>that would automatically mitigate XSS too as a request carrying XSS string wont
>be accepted on server side. (Provided CSRF token validation is done strictly).
It would only mitigate reflected XSS, but not persistent XSS.
In general, I would refrain from telling the developers that CSRF tokens also
mitigate reflected XSS. I fear that the developers could accept this as a
"best practice to fix XSS" with all the negative implications.
"Fixing" reflected XSS with CSRF tokens leads to a tightly coupled security
system, because as soon as CSRF protection fails, you have a much bigger
problem with reflected XSS.
Although, CSRF tokens may be temporal fix for reflected XSS that buys you time
to actually fix the reflected XSS with proper output encoding.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity