You are here

What you should know about web application firewall testing

public://pictures/buehler_franziska-1-960x720.jpg
Franziska Buehler, Systems Architect , Puzzle ITC

If you already have end-to-end tests, UI tests, or other tests that behave like real end users, consider adding a web application firewall (WAF) to those tests starting early in your development lifecycle. It won't take much time, and you'll get a lot of extra security and other benefits.

Ideally, you already have tests for your web applications. If not, create them. Then use the same tests to determine whether you still have full application functionality with the WAF in front of your application. Your tests should still succeed, and your ModSecurity logs should be empty—which means your tests didn't trigger a WAF rule.

As a co-developer of the OWASP Core Rule Set (CRS) for WAF ModSecurity, I feel it's important to share how to bring the WAF into DevOps. I want to reduce the fear of WAFs by automating WAF testing.

Here's how to ensure that your team's use of a WAF goes smoothly.

[ Get up to speed fast on the state of app sec and risk with TechBeacon's new guide. Plus: Get the 2019 Application Security Risk Report. ]

What's a WAF?

A traditional firewall works at the TCP or IP network layer, whereas a WAF blocks attacks at the application layer. It helps protect you against web application attacks and creates a safety net in front of your application. You need it because you can never trust your code 100%.

Unfortunately, WAFs may also block legitimate traffic, causing false positives and production problems. DevOps, testing, and automation make sense only when all components are part of your DevOps/testing/automation pipeline. It doesn't make sense to have everything be fully automated and tested, and then in production put a WAF in front of your application. Make the WAF part of your testing.

If you test your WAF with your web application starting early in the development cycle, you'll ensure that your web application behaves normally. The WAF can help protect against web application attacks such as SQL injection, cross-site-scripting, attacks against the HTTP protocol, and other threats. A WAF won't block all attacks, but it makes it more difficult for attackers to exploit a vulnerability.

Here are the tools you will need for your testing arsenal.

[ Also see: The state of application security testing: 6 best practices ]

The ModSecurity WAF

ModSecurity is a popular WAF that's available as an NGINX, Apache, or IIS module. ModSecurity is the engine, and it needs rules to check every HTTP request and response.

That's where the CRS comes in. It primarily consists of regular expressions, and it decides for each request whether it is legitimate, an attack, or an information leak. Both ModSecurity and the CRS are freely available open-source software and have great community support.

[ Take a deep-dive with our Application Security Trends and Tools Guide, which includes our 2019 App Sec Buyer's Guide. ]

OWASP DevSlop's Pixi

OWASP DevSlop stands for "sloppy DevOps." The goal of this project is to show DevSecOps using several example pipelines, blog posts, a YouTube channel, and more.

DevSlop consists of different modules and pipelines. Some serve as an example of how DevSecOps could be done. And some of its applications or modules serve as a playground to experiment with web application attacks or with ModSecurity and the CRS.

Pixi is the first of many planned applications from the DevSlop project. You can use this intentionally vulnerable web application to experiment with web application attacks. When Pixi is protected with the CRS (another DevSlop module), an example web application attack is no longer successful.

TestCafe

You can use the open-source version of TestCafe to test a web application while simulating how your users would be using it, and you can also use those same tests to test your WAF.

Specifically, you can test whether you still have full application functionality with the WAF in front of your application, and whether the ModSecurity log remains empty.

Set up the pipeline

Testing the WAF manually is a boring and error-prone process. Instead, test the Pixi application with the WAF in front of it using automated, end-to-end tests. You don't have to care about the tests any more: Everything starts automatically and runs each time you commit the web application code into your repository.

[ Also see: 6 test automation tools developers love ]

Get your WAF on

With the right tools and software, you can test any web application with a WAF in front of it, and do so automatically.

This isn't just for WAF experts. A WAF is everyone's friend, as long as you test it. It is your first layer of defense against web attacks. It's open source, free, and creates additional possibilities such as virtual patching, extended logging, and monitoring. You absolutely should have a WAF in your tests and in production.

Want to know more? During my SecureGuild online conference session, "Test your WAF and make it your friend!" I'll introduce ModSecurity and the Core Rule Set. I will show how to use the Pixi-CRS playground to learn more, how to write TestCafe tests to test your application with the WAF, and how to write a CircleCI configuration to automate all these steps. I will give links to more information, blog posts, GitHub repositories with example code, and videos for further reading and learning. The online conference runs from May 20 to 21. Can't make my session? Registered attendees have access to the full session recordings afterwards.

[ Get Report: Gartner Magic Quadrant for Application Security Testing 2019 ]