[WEB SECURITY] Can WAF's block CSRF?

[Ryan Barnett]

Yeah, but if an attacker can script the CSRF attack, they can most likely
also spoof the Referer header as well.  Take a look at Amit Klein's paper on
Exploiting the XmlHTTPRequest Oject in IE for some javascript examples -
http://www.cgisecurity.com/lib/XmlHTTPRequest.shtml.

Jeremiah has a good blog entry on the subject -
http://jeremiahgrossman.blogspot.com/2006/09/csrf-sleeping-giant.html
.

One important thing to point out is that CSRF has 2 attack vectors (that I
know of, perhaps there are more) -

1) Injection via email or third party website.
If an attacker is able to convince a user to click on a weblink (in an email
or webform) or even load up a webpage with injection code, they could submit
the CSRF behind the scenes to the target website.  This is where CSRF
differs from XSS in that the CSRF code does NOT have to be stored or
reflected from the target website.  Getting the target site to actually send
the data back to the client just makes it easier as the client has already
authenticated.  When using a web browser that has not authenticated to the
target site, it is also possible for an attacker to include session
credentials with the injection code (think Session Fixation combo attack).
I have seen many web apps that have extremely poor session id creations that
attackers can predict.

2) XSS type of attack
This is when an attacker gets the target web app to send the CSRF injected
content to a current user.  It is this scenario where you can apply similar
XSS mitigations for input validation.

CSRF is a bit difficult to identify from the web app's persepctive as it is
a legitimate request (calling up a valid function) coming from a legitimate
(authenticated) client.  The key area to focus on to idenfity CSRF is that
the injected request is calling functions that were NOT available in the
current page, meaning that the CSRF request was not generated by the actual
app.  This is where you can potentially identify attacks.

The best mitigation that I found is to implement some form of URL/Parameter
encryption/signing.  Check out the WASC WAF Evaluation Criteria -
http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html#N103B9
   *4.5 Cryptographic URL and Parameter Protection*
**

*Does the WAF support any kind of generic cryptographic URL Encryption to
protect application URLs and parameters against manipulation (forceful
browsing, session riding, etc.)?*
  *4.6 Strict Request Flow Enforcement*
**

*Strict request flow enforcements refers to the technique where a WAF
monitors individual user sessions and keep track of the links followed and
of the links that can be followed at any given time.*
These techniques help to prevent CSRF as the attacker would not be able to
predict the encryption/signing output.  All outbound/inbound parameters
would be inspected and dropped if the encryption or signatures were not
valid.  ModSecurity has a crypto patch add-on that was contributed however I
am not sure if it is ready for prime-time use.  It was more of PoC code.

-- 
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache



On 10/26/06, James Landis <el_spood at yahoo.com > wrote:
>
> Seems that any WAF capable of validating a Referer header is good enough
> for that.
>
> -j
>
> ----- Original Message ----
> From: Jeremiah Grossman <jeremiah at whitehatsec.com>
> To: Web Security < websecurity at webappsec.org>
> Sent: Thursday, October 26, 2006 1:16:41 AM
> Subject: [WEB SECURITY] Can WAF's block CSRF?
>
> That is, can Web Application Firewalls block Cross-Site Request
> Forgery (aka XSRF) attacks?
>
> I believe I know the answer already, but best to put it out there
> anyway and see what people have to say. Any technical information is
> helpful.
>
> Regards,
>
> Jeremiah Grossman
> Chief Technology Officer
> WhiteHat Security, Inc.
> HQ: http://www.whitehatsec.com/
> Blog: http://jeremiahgrossman.blogspot.com/
>
>
>
> ----------------------------------------------------------------------------
> The Web Security Mailing List:
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> The Web Security Mailing List:
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20061026/2caa1634/attachment.html>