[WEB SECURITY] Anti-CSRF mesaues will mitigate XSS

lavakumar kuppan lavakumar.in at gmail.com
Fri Jun 25 16:41:51 EDT 2010


Nilesh,

ClickJacking can be used to bypass Anti-CSRF measures in many instances.

Ref:
http://blog.andlabs.org/2010/03/bypassing-csrf-protections-with.html
http://www.contextis.co.uk/resources/white-papers/clickjacking/Context-Clickjacking_white_paper.pdf

So now if your protection against XSS was only CSRF tokens then by using
ClickJacking an attacker can perform an XSS attack.

Tomorrow we might have a new technique to bypass CSRF countermeasures.

And everytime that happens the application would be open to two attacks CSRF
as well as XSS.

Moreover, if the attacker can perform a Session fixation attack and use his
session's Anti-CSRF tokens to perform XSS, the user would still be in
trouble.

Because the attacker can then steal locally stored data - LSOs, cookies,
LocalStorage, Web SQL Storage, Password Manager (
http://ha.ckers.org/weird/xss-password-manager.html) etc.

And with all the Cross Domain communication possibilities in HTML5, the
attacker could start attacking the other applications that communicate with
the vulnerable application.

There has been some great points from others as well and so far its been a
overwhelming NO to using Anti-CSRF for XSS protection.

Hope this gives enough reasons for the programmers to write a few extra
lines of code to encode the user output ;)

Cheers,
Lava
http://www.andlabs.org





2010/6/26 MustLive <mustlive at websecurity.com.ua>

> Hello Nilesh!
>
> My suggestion to you and all people in such cases - always fix all holes.
> There were similar cases in my practice, mentioned by you, when developers
> was trying to argument to not fix XSS due to CSRF protection. Like in 2006
> when I found many holes in WordPress 2.0.3 and developers trying to tell me
> regarding one XSS that they have anti-CSRF tokens at that page, so no need
> to fix that hole, but I said them that all holes must be fixed, and they
> fixed. So fixed hole it's fixed exactly this hole (not some other hole).
>
> Because I meet a lot of such cases, especially concerning XSS, for many
> years, when people don't want to fix XSS holes, because they fixed other
> hole (not XSS), or implemented protection from other attacks (not XSS), and
> then saying they have mitigated all XSS attacks. Most often it's regarding
> Session fixation protection, but sometimes it's regarding CSRF protection
> like in this case (or above-mentioned case with WP). So I need to explain
> people that all holes must be fixed.
>
>
>  The application was rejecting any external request.
>>
>
> Nilesh, you must understand, that there are methods which allow to bypass
> anti-csrf filters, so if XSS will be left unfixed, then sometime it can be
> used for attack. All these bypassing methods use other holes, but because
> there were, are or will be other holes at that site, there is always
> probability of using these XSS holes. So it's better to fix them.
>
> For example in article Redirectors: the phantom menace
> (http://www.webappsec.org/lists/websecurity/archive/2009-09/msg00021.html)
> I
> wrote about using of Redirectors to bypassing anti-csrf filters (based on
> referrer) to conduct CSRF attacks.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> * From: nilesh kumar <nileshkumar83 at xxxxxxxxxxx>
> * Subject: [WEB SECURITY] Anti-CSRF mesaues will mitigate XSS
> * Date: Thu, 24 Jun 2010 14:09:27 +0530 (IST)
>
>
>  Hi List,
>>
>> Although it's not a new idea. But during an assessment of an application,
>> I=
>>  and my colleague was discussing about a scenario in the application. The
>> a=
>>
>> pplication had login section behind which there were few pages that were
>> vu=
>> lnerable to Reflected XSS. Application was also vulnerable to CSRF.=20
>>
>> Needless to say that we suggested anti-CSRF measures for the application.
>> A=
>>
>> lthough we also suggested anti-XSS measures but the anti-CSRF measures
>> were=
>>  good enough to mitigate any attempt to exploit the reflected XSS flaws on
>> =
>> the pages behind authentication. The application was rejecting any
>> external=
>>  request.=20
>>
>>
>> So any attempt to exploit the reflected XSS will bear no fruit in scenario
>> =
>> like this.
>>
>> Your valuable thoughts?
>>
>> Thanks & Regards,
>> Nilesh Kumar,
>> Security Analyst
>> Honeywell, India
>> http://nileshkumar83.blogspot.com
>>
>
>
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to
> the confirmation email
>
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
>


-- 
Cheers,
Lava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20100626/42b6fa76/attachment.html>


More information about the websecurity mailing list