How are you tackling CSRF?
Hello guys!
Concerning the topic "How are you tackling CSRF" which was started by
Jeremiah, I want to tell the next.
- 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.
- 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.
-
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. -
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
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.
Hang on a sec. W3C recommendations state that GET requests should be
idempotenent (non-state changing) and therefor should not require CSRF token
protection.
Admittedly, this is the ideal. Many developers use GET requests for state
changing operations.
But GET based tokens cause serious scalability problems when you are dealing
with CDN's (content delivery networks) like Akamai.
I could go on, but the key here is that this is not about "developer
laziness". CSRF defense is more complex of a design decision than appears at
first glance.
More here:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Jim Manico
On Apr 23, 2011, at 3:59 PM, "MustLive" mustlive@websecurity.com.ua wrote:
- 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.
Hi Jim!
"Prevention Cheat Sheet" - sounds interesting. It's good to know that OWASP
made such Prevention Cheat Sheet and particularly for CSRF (as I saw there
are other Prevention Cheat Sheets). This will be helpful for web developers
to create reliable protections against this issue. For example, sometimes
web developers ask me about methods to protect against CSRF. So instead of
long description about pro and contra of different protection methods, it'll
be simpler to give people read this document.
Hang on a sec. W3C recommendations state that GET requests should be
idempotenent
First, many developers use tokens for GET requests (for example I more
prefer to user referer checking for GET requests).
Second, how many developers reads W3C recommendations.
Third, I was talking about internal forms (in users account, i.e.
post-authorization form), and in such case not W3C with their
recommendations, nor Akamai will see anything in that users account of that
site, so there will be no questions and no issues which you mentioned
concerning tokens in GET request.
Fourth and the most important - if there is a functionality (accessible via
GET or POST) which can be subject to CSRF attack and so need to be secured
against them, it must be secured. If developers have choose tokens, then by
tokens - regardless GET or POST is it and any W3C can't stopped the securing
process. And generally there must be no such official standards or
recommendations that decrease security of sites and web applications ;-).
So in that case it was looking as developers laziness. Especially if they
put tokens not only to POST forms, but to some GET links, but not all
(leaving part of the holes unfixed). Also sometimes I saw selective approach
from developers - as from my clients, as in CMS (it's already not laziness,
but developers decision where to make anti-CSRF protection and where not).
For example I saw such cases in WordPress, Drupal and Joomla - and in
particular they concerned GET requests, some of which had tokens and some
not. But there are such engines where every functionality is protected
against CSRF, so it depends on developer.
Besides, last Thursday I wrote an article "Attacks on unprotected login
forms" (soon I'll post English version of it to the list), where I also
mentioned about CSRF attacks.
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
From: James Manico
To: MustLive
Cc: websecurity@lists.webappsec.org
Sent: Sunday, April 24, 2011 11:27 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
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.
Hang on a sec. W3C recommendations state that GET requests should be
idempotenent (non-state changing) and therefor should not require CSRF token
protection.
Admittedly, this is the ideal. Many developers use GET requests for state
changing operations.
But GET based tokens cause serious scalability problems when you are dealing
with CDN's (content delivery networks) like Akamai.
I could go on, but the key here is that this is not about "developer
laziness". CSRF defense is more complex of a design decision than appears at
first glance.
More here:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Jim Manico
On Apr 23, 2011, at 3:59 PM, "MustLive" mustlive@websecurity.com.ua wrote:
- 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.
Hi,
On Sun, Apr 24, 2011 at 04:10:33AM +0300, MustLive wrote:
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
Is it still true? I guess that modern WAFs (commercial ones) are able to
add anti-CSRF tokens into all POST hidden fields (and probably also anti-CSRF
tokens to GET requests) and transparently remove them (after verification)
before sending them to the backend application. So it should be completely
transparent anti-CSRF solution even for completely CSRF vulnerable applications
(e.g. those ones which use session ID just in cookies with no CSRF protection).
Pavol
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]
Hi Pavol!
Is it still true? I guess that modern WAFs (commercial ones) are able to
It's from what I know :-) - I haven't heard about WAFs which can protect
against CSRF (and it must be completely transparent). If there will be such
WAFs which will be protecting against CSRF completely transparent and
without creating of problems for correct work of the sites, then it'll be
good solution for protecting all those multiple webapps which are vulnerable
to CSRF (and there are a lot of them, as old as new ones, which partly or
completely vulnerable to CSRF).
Taking into account that it's hard task it'll be not easy to make such 100%
transparent and 100% reliable WAF with CSRF protection (which must not only
protect all requests, especially important ones, e.g. with tokens, but also
automatically decided which places are important and where for example not
needed to add tokens, carefully decide in case of GET requests, not overdo
with tokens where it's not needed to not overload the server, etc.).
Meanwhile the one and only reliable protection method - it's manually
protecting against CSRF (by writing appropriate programming code).
Besides, concerning CSRF topic - recently I wrote in my article "Attacks on
unprotected login forms"
(http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html)
also about CSRF attacks on login forms. It can be as direct CSRF attacks
(e.g. for remote loginning), as for conducting of other attacks, such as XSS
and Redirector (like in MyBB which I mentioned in the article).
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
From: "Pavol Luptak" pavol.luptak@nethemba.com
To: "MustLive" mustlive@websecurity.com.ua
Cc: websecurity@lists.webappsec.org
Sent: Saturday, April 30, 2011 8:26 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
Hi,
On Sun, Apr 24, 2011 at 04:10:33AM +0300, MustLive wrote:
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
Is it still true? I guess that modern WAFs (commercial ones) are able to
add anti-CSRF tokens into all POST hidden fields (and probably also
anti-CSRF
tokens to GET requests) and transparently remove them (after verification)
before sending them to the backend application. So it should be completely
transparent anti-CSRF solution even for completely CSRF vulnerable
applications
(e.g. those ones which use session ID just in cookies with no CSRF
protection).
Pavol
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel:
+421905400542]
Hi Pavol,
Barracuda Web Application Firewall effectively blocks CSRF. You check the
configuration options in waf.barracuda.com.
Thank you,
Ramesh
On Tue, May 3, 2011 at 12:46 AM, MustLive mustlive@websecurity.com.uawrote:
Hi Pavol!
Is it still true? I guess that modern WAFs (commercial ones) are able to
It's from what I know :-) - I haven't heard about WAFs which can protect
against CSRF (and it must be completely transparent). If there will be such
WAFs which will be protecting against CSRF completely transparent and
without creating of problems for correct work of the sites, then it'll be
good solution for protecting all those multiple webapps which are vulnerable
to CSRF (and there are a lot of them, as old as new ones, which partly or
completely vulnerable to CSRF).
Taking into account that it's hard task it'll be not easy to make such 100%
transparent and 100% reliable WAF with CSRF protection (which must not only
protect all requests, especially important ones, e.g. with tokens, but also
automatically decided which places are important and where for example not
needed to add tokens, carefully decide in case of GET requests, not overdo
with tokens where it's not needed to not overload the server, etc.).
Meanwhile the one and only reliable protection method - it's manually
protecting against CSRF (by writing appropriate programming code).
Besides, concerning CSRF topic - recently I wrote in my article "Attacks on
unprotected login forms" (
http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html)
also about CSRF attacks on login forms. It can be as direct CSRF attacks
(e.g. for remote loginning), as for conducting of other attacks, such as XSS
and Redirector (like in MyBB which I mentioned in the article).
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message ----- From: "Pavol Luptak" <
pavol.luptak@nethemba.com>
To: "MustLive" mustlive@websecurity.com.ua
Cc: websecurity@lists.webappsec.org
Sent: Saturday, April 30, 2011 8:26 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
Hi,
On Sun, Apr 24, 2011 at 04:10:33AM +0300, MustLive wrote:
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
Is it still true? I guess that modern WAFs (commercial ones) are able to
add anti-CSRF tokens into all POST hidden fields (and probably also
anti-CSRF
tokens to GET requests) and transparently remove them (after verification)
before sending them to the backend application. So it should be completely
transparent anti-CSRF solution even for completely CSRF vulnerable
applications
(e.g. those ones which use session ID just in cookies with no CSRF
protection).
Pavol
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel:
+421905400542]
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Just remember to keep it on and active! ;)
On Tue, May 3, 2011 at 7:12 AM, ramesh mv mvram03@gmail.com wrote:
Hi Pavol,
Barracuda Web Application Firewall effectively blocks CSRF. You check the
configuration options in waf.barracuda.com.
Thank you,
Ramesh
On Tue, May 3, 2011 at 12:46 AM, MustLive mustlive@websecurity.com.uawrote:
Hi Pavol!
Is it still true? I guess that modern WAFs (commercial ones) are able to
It's from what I know :-) - I haven't heard about WAFs which can protect
against CSRF (and it must be completely transparent). If there will be such
WAFs which will be protecting against CSRF completely transparent and
without creating of problems for correct work of the sites, then it'll be
good solution for protecting all those multiple webapps which are vulnerable
to CSRF (and there are a lot of them, as old as new ones, which partly or
completely vulnerable to CSRF).
Taking into account that it's hard task it'll be not easy to make such
100% transparent and 100% reliable WAF with CSRF protection (which must not
only protect all requests, especially important ones, e.g. with tokens, but
also automatically decided which places are important and where for example
not needed to add tokens, carefully decide in case of GET requests, not
overdo with tokens where it's not needed to not overload the server, etc.).
Meanwhile the one and only reliable protection method - it's manually
protecting against CSRF (by writing appropriate programming code).
Besides, concerning CSRF topic - recently I wrote in my article "Attacks
on unprotected login forms" (
http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html)
also about CSRF attacks on login forms. It can be as direct CSRF attacks
(e.g. for remote loginning), as for conducting of other attacks, such as XSS
and Redirector (like in MyBB which I mentioned in the article).
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message ----- From: "Pavol Luptak" <
pavol.luptak@nethemba.com>
To: "MustLive" mustlive@websecurity.com.ua
Cc: websecurity@lists.webappsec.org
Sent: Saturday, April 30, 2011 8:26 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
Hi,
On Sun, Apr 24, 2011 at 04:10:33AM +0300, MustLive wrote:
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
Is it still true? I guess that modern WAFs (commercial ones) are able to
add anti-CSRF tokens into all POST hidden fields (and probably also
anti-CSRF
tokens to GET requests) and transparently remove them (after verification)
before sending them to the backend application. So it should be completely
transparent anti-CSRF solution even for completely CSRF vulnerable
applications
(e.g. those ones which use session ID just in cookies with no CSRF
protection).
Pavol
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel:
+421905400542]
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Hi Ramesh!
I want to tell you the next concerning Barracuda Web Application Firewall. I
didn't use it and hadn't seen at web sites online, to test it and to see how
effectively it blocks CSRF attacks. But if you've used it and know its
efficiency, then it can be so (but always better to see by yourself).
Still there are moments which give doubts in efficiency of Barracuda WAF.
-
Barracuda have holes at their sites and not making effective security
audit of their web sites. As it can be seen from XSS holes which I've found
in February (announced and informed Barracuda in April) and in April
(announced and informed Barracuda in June). -
Barracuda haven't responded and fixed the holes - i.e. they ignored them.
It's just 2 + 5 XSS holes it total (at my quick look in February and April
at one their site) and there can be much more of them - it's not 900 DoS
holes, which I found in June at Sophos' web site, but still the holes. And
having vulnerabilities at their sites, ignoring to find them and to fix them
show company's attitude to web security. -
In April their site was hacked, which leaded to sensitive information
disclosure. Hack was made via SQL Injection and existence of such holes was
predictable from those holes which I found at their site earlier. -
They was not using WAF at their vulnerable and hacked sites (and quite
possible on a lot of other their sites) and still not using it at that
vulnerable site with multiple XSS. Are they fearing to use their own product
on their own sites, fearing it's not effective enough? -
In June there were disclosed Remote Command Execution vulnerabilities in
Barracuda NG Firewall and phion netfence.
All of these not give enough confidence in efficiency of their WAF, but I'm
wishing good luck to them and their security products ;-).
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
From: ramesh mv
To: MustLive
Cc: Pavol Luptak ; websecurity@lists.webappsec.org
Sent: Tuesday, May 03, 2011 3:12 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
Hi Pavol,
Barracuda Web Application Firewall effectively blocks CSRF. You check the
configuration options in waf.barracuda.com.
Thank you,
Ramesh
On Tue, May 3, 2011 at 12:46 AM, MustLive mustlive@websecurity.com.ua
wrote:
Hi Pavol!
Is it still true? I guess that modern WAFs (commercial ones) are able to
It's from what I know :-) - I haven't heard about WAFs which can protect
against CSRF (and it must be completely transparent). If there will be such
WAFs which will be protecting against CSRF completely transparent and
without creating of problems for correct work of the sites, then it'll be
good solution for protecting all those multiple webapps which are vulnerable
to CSRF (and there are a lot of them, as old as new ones, which partly or
completely vulnerable to CSRF).
Taking into account that it's hard task it'll be not easy to make such 100%
transparent and 100% reliable WAF with CSRF protection (which must not only
protect all requests, especially important ones, e.g. with tokens, but also
automatically decided which places are important and where for example not
needed to add tokens, carefully decide in case of GET requests, not overdo
with tokens where it's not needed to not overload the server, etc.).
Meanwhile the one and only reliable protection method - it's manually
protecting against CSRF (by writing appropriate programming code).
Besides, concerning CSRF topic - recently I wrote in my article "Attacks on
unprotected login forms"
(http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html)
also about CSRF attacks on login forms. It can be as direct CSRF attacks
(e.g. for remote loginning), as for conducting of other attacks, such as XSS
and Redirector (like in MyBB which I mentioned in the article).
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message ----- From: "Pavol Luptak"
pavol.luptak@nethemba.com
To: "MustLive" mustlive@websecurity.com.ua
Cc: websecurity@lists.webappsec.org
Sent: Saturday, April 30, 2011 8:26 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
Hi,
On Sun, Apr 24, 2011 at 04:10:33AM +0300, MustLive wrote:
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
Is it still true? I guess that modern WAFs (commercial ones) are able to
add anti-CSRF tokens into all POST hidden fields (and probably also
anti-CSRF
tokens to GET requests) and transparently remove them (after verification)
before sending them to the backend application. So it should be completely
transparent anti-CSRF solution even for completely CSRF vulnerable
applications
(e.g. those ones which use session ID just in cookies with no CSRF
protection).
Pavol
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel:
+421905400542]