[WEB SECURITY] How are you tackling CSRF?

MustLive mustlive at websecurity.com.ua
Sat Apr 23 21:10:33 EDT 2011


Hello guys!

Concerning the topic "How are you tackling CSRF" which was started by
Jeremiah, I want to tell the next.

1. How are you tackling CSRF?

I'm discovering them manually - as I always do for all vulnerabilities. I'm
not using and never used automatic scanners for finding any class of
vulnerabilities.

2. What about automatic approach for discovering CSRF / protecting against
CSRF.

Not vulnerabilities scanners can adequately find CSRF holes (some don't do
it at all, some don't do it reliably), nor WAFs can adequately protect
against CSRF holes (the same as with scanners). Take into account that there
can be CSRF protection at the site, but it can be vulnerable - in this case
automatic solutions (scanners and WAFs) can't help reliably.

> But, the as it normally happens, the bad guys have been showing us how
> damaging CSRF can really be.

On this I can say, that not only bad guys, but good guys also can show real
danger of any class of vulnerabilities ;-). For example from 2006 I'm
regularly demonstrating "in live" for some admins the reality and the
dangers of such holes as XSS (as persistent, as reflected), and also for XSS
via CSRF attacks. And when these admins see the reality of the attack, then
there are more chances, that they will understand and fix (not all of them
made correct decisions and fixed holes, but I have many positive cases).

Concerning CSRF I'll also draw your attention that such holes also can be
used for financial attacks (which shows how they can be danger in real). As
I wrote in December in article Business Logic vulnerabilities via CSRF
(http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2010-December/007283.html).

And in my discussion about Vulnerabilities at PCI DSS sites
(http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2010-December/007332.html)
I've told about such sites with Business Logic flaws which can be triggered
via CSRF (and all of these sites with BL-CSRF holes ignoring to fix them
for years). On one EPS, as I wrote at my site with examples of PoCs, it can
lead to stealing of cash (even millions of dollars) from user's account or
his credit card connected to the account.

Also guys in your discussion about tackling CSRF (manual or automatic,
especially automatic) draw attention to the next.

1. Using of not working CSRF protection (which can be bypassed - the tokens
can be not checked by script, or the algorithm is weak, or the tokens are
guessable), which I mentioned above and it was mentioned by Rohit.

2. Protecting only POST requests with tokens, but not GET. It looks like
some web developers are lazy (or it's hard for them) to add tokens to GET
requests. Similarly as it can be lazy or hard to do above-mentioned checking
of the tokens :-).

> As far as our experience goes, if post-login, some forms do not contain
> anti-CSRF tokens, it is fair chance that rest of forms will also be the
> same.

Yes, in my experience I also saw many such cases. Also there were such cases
where in some forms there were implemented tokens, but in some not
(developers just forget, especially if it's new practice for them, after my
informing them about CSRF - it requires time to become implementing CSRF
protections in every form, including in every new one). But two issues
mentioned above are also widespread, and with years become more common, when
web developers become implementing (often incorrectly) CSRF protections.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua






More information about the websecurity mailing list