String-Matching in a Web Application Firewall [WAF]

In a review of a loaner web application firewall, a colleague noticed that it seemed to be regex-centric.  I asked if it was possible for him to extract a list of the regexs used by the applicance and then send me a copy of the set.  I really didn’t have much hope for getting the list, but there it was in my email that evening.

My colleague had set of a test environment having an application server, the WAF (web application firewall), a traditional firewall, and his client PC.  All traffic travelling between the client PC and the application server had to traverse the firewall and the WAF.  He reported that the WAF did a good job identifying and denying his cross site scripting (XSS) and SQL injection attacks on the web application, and did not exhibit excessive false positives during his testing.  It appeared to be equally capable regardless of attempts to attack form fields, hidden fields, or any type of POST or GET values.  Based on that finding alone, this appliance might be worth its cost for specific, known-vulnerable, high-risk situations where it is impossible to remediate the application weaknesses or those repairs will take an extended period of time.  Vulnerable vendor applications come to mind…

So, based on a quick review of the information in the email from my associate, the WAF organizes its regex patterns into the following categories:command injection, credit card numbers, cross site scriptin (XSS), directory traversal, protected files, protected directories, forbidden UNC references, LDAP injection, restricted characters, quotes, carriage return line feed, carriage return, tab,  SQL injection, and SSI injection.  Given the layout of this data, it was difficult for me to immediately determine whether there was a bias or focus on one area over another, so I spent some time reviewing the regexes more carefully.  They fall into the following distribution:

124 command injection,
92 SQL injection,
71 cross site scripting (XSS),
29 restricted characters,
14 SSI injection,
12 credit card numbers,
8 LDAP injection,
4 protected files,
4 protected directories,
2 directory traversal,
2 carriage return line feed,
1 forbidden UNC references,
1 carriage return,
1 tab.

They appear to be written in a way that requires many of them to be used in combination with each other in order to fire positive alarms without too many false positives.  The appliance does not reveal how it assembles these combinations, or what rules it uses when it identifies certain patterns of rule-firing.

Also, there are some vulnerability categories that were not represented in the regex category listing.  When I think of the common web application vulnerability lists (for example OWASP) along with my own environment, I wonder about the absence of XPath injection, cookie poisoning, some common types of URI parameter tampering, and inappropriate error messages.  There are more as well…

There are certain types of vulnerable applications for which it might be a poor match.  If the application vulnerabilities are clustered around inappropriate use of URI values for identification or access control, then it appeared that this applicance would be especially difficult to configure so that it might resist misuse of those URI-related vulnerabilities.

Based only on reading and some brief experimenting, it appears that WAFs may fit some difficult risk management issues that we already have or expect to see in the near future.  I am very interested in any experience that you might have employing web application firewalls in your infrastructure.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: