Free-to-use feature can help users gauge whether the CRS protects against payloads

OWASP ModSecurity Core Rule Set sandbox launched to help security researchers test new CVEs

Security researchers can now test payloads against the OWASP ModSecurity Core Rule Set with a new sandbox released by the project maintainers.

The Core Rule Set, also known as CRS, is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls (WAFs).

It aims to protect web applications from a wide range of attacks, including the OWASP Top Ten.


READ MORE Lessons learned: How a severe vulnerability in the OWASP ModSecurity Core Rule Set sparked much-needed change


Today (December 9), the team behind the CRS have released a sandbox that enables researchers to test against it without the need to install or configure a ModSecurity box.

In a blog post, the team explained that the sandbox is designed for use by people facing a new CVE who “want to find out whether CRS could buy them time”.

“It’s also quite useful for the CRS project, since we can quickly test payloads against various versions and backends to confirm GitHub issues (false negatives, false positives),” the post reads.

‘Unintelligible ModSecurity logs’

Christian Folini, project lead, told The Daily Swig that a sandbox API was created following “regular” conversations with security researchers about how they can use the CRS without having to set up a CRS docker with the correct version and what the team deems “the painful interpretation of the unintelligible ModSecurity logs”.

Folini said: “I remember a conversation with PortSwigger’s James Kettle and Gareth Hayes who told us at AppSec Amsterdam in 2019 they would be open to adding information about payloads being blocked by an open source WAF like CRS as part of their publications, but only if the burden of setting up containers with proper CRS configuration was taken from them.

“Essentially a CRS sandbox was needed.”


Read more of the latest infosec industry news


The sandbox was officially in operation as of October this year. “As with every new development, we had to try out a few approaches until we found one that would work consistently,” Folini added.

“An alternative architecture where the gateway server would intercept the connection and inject the response on the TCP level would have been slick, but too complex.

“The reverse proxy + openresty setup we settled on is not quite ideal when it comes to certain protocol attacks, but it is relatively simple and very stable.”

Future plans

The sandbox, which is free to use, is hosted on AWS. The team are collecting logs, though the IP addresses will be anonymized.

Folini also touched on plans for adding further features, including the ability to create a users’ ‘hall of fame’ and the option to share information on payloads with others.

He explained: “People should be able to retrieve previous payloads and analyze them.

“That would allow somebody to text an ID to a friend and go, ‘Hey, look up this complex HTTP request’.

“Supporting these IDs could allow the sandbox to become a tool for teams working on exploits. Or a way to store them and you only [need to] keep the IDs.”

More technical detail on how the sandbox works can be found in the blog post.


YOU MAY ALSO LIKE WAF bypass: ‘Severe’ OWASP ModSecurity Core Rule Set bug was present for several years