[prev in list] [next in list] [prev in thread] [next in thread] 

List:       websecurity
Subject:    Re: [WEB SECURITY] How are you tackling CSRF?
From:       "MustLive" <mustlive () websecurity ! com ! ua>
Date:       2011-08-30 20:54:53
Message-ID: 00f801cc6757$4017f7b0$9b7a6fd5 () ml
[Download RAW message or body]

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.

1. 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).

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

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

4. 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?

5. 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]



_______________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]