Web Application Firewalls - Let’s call a Fig a Fig
I am writing the first draft of the OWASP Web Security Evaluation Criteria this month and need to consider the role of the web application firewall or WAF. I have long been troubled by the marketing surrounding web application firewalls and especially troubled by the PCI DSS’s implicit endorsement of them. They make an assertion that is just plain wrong by implying that a web application firewall is comparable to a code review. You can choose to have either with the PCI DSS. Because of this and the “vendor fest” that has ensued around PCI DSS, I have been expecting mails like this one on the webappsec mailing list for a while. It is misguided at best.
The view of a respected VC investor given to me in private was this. ‘The market never materialized the way people thought, the enterprise and CSO’s doesn’t like or believe in them; the network teams do but don’t control the applications and when Cisco, Juniper, CheckPoint and anyone else that matters don’t seem to think its important enough to buy one then we are left with a lot of small niche firms and unhappy moneymen. That said the PCI (DSS) may just be the savior everyone is hoping for but most people still seem to think its like putting a plaster over a flesh wound.’
Ivan Ristic, the creator of ModSecurity gave an accurate view of web application firewalls at an OWASP London meeting a few years back. It was a pleasure to listen to such a balanced and articulate view from someone who clearly understands the technology, market space and has a big personal stake in the game. He essentially put forward a view that they can have a place to play in protecting from a specific set of web application security attacks but are nor ever will be a panacea. My view is similar, they could be a useful part of a defense in depth strategy but you need to understand their limitations.
Cut through the marketing BS and you will find in general there are two types of WAF; protocol analyzers that operate on HTTP traffic looking for signatures in the data stream and a new breed that additionally operate on the application stack at run-time. The second approach has some clear advantages but still has practical limitations.
If you take a step back and look at the range of web security issues we are facing you can order them into a security frame like the one below.
- Authentication -How users and components authenticate
- Authorization - How authorization decisions are made
- User Management - How are passwords stored, reset etc
- Data Validation -How is data validated to protect from XSS, SQL injection etc
- Data Protection - How is data stored and passed around securely
- Security Monitoring - What is written to logs, how are exceptions handled
- Infrastructure Management - The OS, FW etc
- Configuration Management - CAS, JRE etc
I am not going to cast everyone with the same brush but in general what I see is that what much of the WAF marketing assumes is that the attack vector for all attacks come in the front door and that a web application is likely a single or small cluster of hosts.
Here is a dose of reality. An enterprise web site usually look like this.
A single checkpoint security pattern (see Yoder) will not give you a high level of assurance. Ignoring the vast range of attack patterns, attack vectors and the reality of modern architectures (I have not even touched on the implications of SOA and REST here) would leave business with a false sense of security.
In the OWASP Web Security Certification Criteria we will be calling a “fig a fig”. A WAF can have a place to play in protecting from a specific set of web application security attacks but are nor ever will be a panacea.
Side-story: I had dinner a few weeks back with a guy from a well known code review tools company. Actually he invited me for dinner and then his credit card was rejected so I ended up reaching into my pocket which was a fitting end to a disappointing dinner. He stated blatantly with a smug smile (para-phrasing as I can’t remember the exact words) ‘we think PCI is fantastic, we have both a web application firewall and code review tools so either way we get to make a sale’. I lost all respect I had for that company that night. I thought they had a pedigree and could be trusted in the software security space.
June 13, 2007 at 1:22 pm
I recently got concerned about another possible security problem with web services, discussed inmore detail in the Lustratus Litebytes blog, http//blog.lustratusresearch.com. The issue I am worried about is the malicious use of recursive XML to foul up the XML parser, perhaps offering an opportunity for a Denial of Service attack.
June 13, 2007 at 11:33 pm
Steve
I think I am right in saying XML recursion with SAX parsers has been a “known” issue for a while. I have some links somewhere I will post if I can find them with some proof of concept schema and docs.
September 25, 2007 at 8:35 am
[...] Ticking Time Bomb - PCI Application Security A while back I wrote a blog post called Lets call a Fig a Fig about the limitations of web application firewalls and the sheer ludicrousness of a security [...]