[WEB SECURITY] Anti-CSRF mesaues will mitigate XSS
mustlive at websecurity.com.ua
Fri Jun 25 14:58:11 EDT 2010
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
wrote about using of Redirectors to bypassing anti-csrf filters (based on
referrer) to conduct CSRF attacks.
Best wishes & regards,
Administrator of Websecurity web site
* 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,
> and my colleague was discussing about a scenario in the application. The
> pplication had login section behind which there were few pages that were
> lnerable to Reflected XSS. Application was also vulnerable to CSRF.=20
> Needless to say that we suggested anti-CSRF measures for the application.
> lthough we also suggested anti-XSS measures but the anti-CSRF measures
> good enough to mitigate any attempt to exploit the reflected XSS flaws on
> the pages behind authentication. The application was rejecting any
> 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
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
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
WASC on Twitter
More information about the websecurity