[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.

Rohit




________________________________
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 
>matter.
> 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.

Cheers,
Sebastian
-------------- 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