[WEB SECURITY] How are you tackling CSRF?

Rohit Pitke 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?

Hi Rohit,

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).
> Thoughts?

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...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110426/edff63d2/attachment-0003.html>

More information about the websecurity mailing list