Garter’s Magic Quadrant (MQ) 2015 for Web Application Firewalls (WAF) estimates that the global WAF market size is as big as $420 million, with 24 percent annual growth, making a Web Application Firewall one of the most popular preventive and/or detective security controls currently being used for web applications.
PCI DSS 3.1 requirement 6.6 suggests WAF deployment as an alternative to vulnerability scanning while ISACA’s “DevOps Practitioner Considerations” includes WAF in the 10 key security controls that companies need to consider as they embrace DevOps to achieve reduced costs and increased agility.
Nowadays, a number of large and midsize companies offer various WAF solutions, usually packaged together with DDoS protection, CDN, ADC and other related offerings. Amazon Web Services (AWS) has itself recently launched its own WAF service.
Gartner predicts that by 2020, more than 60 percent of public web applications will be protected by a WAF. However, in 2015 Gartner had only one vendor listed in its WAF MQ as a Leader (Imperva), and only two vendors listed as Visionaries (DenyAll and Positive Technologies). All other vendors are either Niche Players or Challengers. Many more WAF vendors were simply not present in the MQ for not meeting the inclusion criteria.
Last year, security researcher Mazin Ahmed published a White Paper to demonstrate that XSS protection from almost all popular WAF vendors can be bypassed. XSSPosed (the Open Bug Bounty project) prior to announcing its private and open Bug Bounty programs, published new XSS vulnerabilities on the largest websites (including Amazon) almost every day and was effectively an insightful resource for observing just how security researchers bypassed almost every WAF mentioned in the Magic Quadrant. The emerging trend of RASP (Runtime Application Self Protection) can also be bypassed using similar techniques as for WAF bypass.
High-Tech Bridge recently published research on a white label WAF named ModSecurity which demonstrated that a WAF can be used to mitigate even such complicated vulnerabilities as Improper Access Control or Session Fixation. Sadly, many commercial vendors do not provide even a half of ModSecurity’s technical ability and flexibility for virtual patching. However, High-Tech Bridge’s research also highlighted that ModSecurity OWASP CRS can be bypassed in default configuration, and that creation of custom rulesets may be very complicated and time-consuming.
There are five main reasons why WAF protection often fails these days:
1. Negligent deployment, lack of skills and different risk mitigation priorities
Many companies simply don’t have competent technical personnel to maintain and support WAF configuration on a daily basis. Not surprisingly, they just put their WAF into detection mode (without blocking anything) and don’t even care about reading the logs.
2. Deployment only for compliance purposes
Midsize and small companies frequently install WAFs just to satisfy a compliance requirement. They don’t really care about practical security, and obviously won’t care about maintaining their WAF.
3. Complicated diversity of constantly evolving web applications
Today almost every company uses in-house or customized web applications, developed in different programming languages, frameworks and platforms. It’s still common to see CGI scripts from the 90s in pair with complex AJAX web applications using third-party APIs and web services in the cloud. Moreover, web developers need to update their web applications almost every day to meet business requirements. Obviously, such a dynamic and diverse environment can hardly be protected even by the best WAF and the most competent engineers.
4. Business priorities domination over cybersecurity
It’s almost unavoidable that your WAF will cause some false-positives by blocking legitimate website visitors. Usually, after the first complaint to the management from an unhappy customer who could not pay for the service and left for a competitor, WAF is being definitely moved into detection-only mode (at least until the next QSA audit).
5. Inability to protect against advanced web attacks
By design, a WAF cannot mitigate unknown application logic vulnerabilities, or vulnerabilities that require a thorough understanding of application's business logic. Few innovators try to use an incremental ruleset hardening in pair with IP reputation, machine learning and behavioural white-listing to defend against such vulnerabilities. However, they need to pass complicated learning cycles that take quite a lot of time, and are not yet reliable enough.
A Web Application Firewall remains a pretty complicated security control to deploy and maintain within an organization.
However, a WAF remains probably the only preventive security control for web applications, significantly reducing the risks of web vulnerabilities exploitation. A properly configured WAF can prevent simple vectors of the most common web vulnerabilities (such as XSS and SQL injections), even in very dynamic and complicated environments. Moreover, if for a reason it’s impossible to patch the vulnerable web application source code or apply vendor’s patch, virtual patching via WAF can be a life-saver.
Nevertheless, in no case should a WAF be considered a panacea against web attacks, and shall always be completed by other security controls, such as Vulnerability Scanning, Developer Security Training and Continuous Monitoring, as suggested by ISACA.
Yan Borboën, partner at PwC Switzerland, MSc, CISA, CRISC, comments: “As of today, we can say that cyberattacks have become the new normality in our today’s digitally connected world. There is no 'magic bullet' for effective cybersecurity, it’s a journey which is starting with the identification of your key risks and your crown jewels (i.e. client data, intellectual property, etc) and then to find the right mix between technologies, processes, and people measures.”
Being insufficient to properly mitigate complicated security flaws in modern web applications, a Web Application Firewall still remains a necessary security control within organizations.
This article originally appeared online at CSO.