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.
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'll 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.
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.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
