The CRS Plugin Mechanism
Plugins are not part of the CRS 3.3.x release line. They will be released officially with the next major CRS release 4.x. In the meantime, you can use them with one of the stable releases by following the instructions below. What are Plugins? Plugins are sets of additional rules that you can plug in to your web application firewall in order to expand CRS with complementary functionality or to interact with CRS. Rule exclusion plugins are a special case: these are plugins that disable certain rules to integrate CRS into a context that is otherwise likely to trigger certain false alarms.
Disabling Request Body Access in ModSecurity 3 Leads to Complete Bypass
If you are running ModSecurity 3 with request body access disabled, then I have some bad news. Please sit down, this will be a while. If you are running ModSecurity 2, or you give the engine access to the request body, then you are not affected. But maybe you want to read this post nevertheless. I’ll be discussing a new ModSec3 vulnerability an upcoming new CRS feature and some fundamental problems affecting existing ModSecurity rule sets.
CVE-2020-15598 - ModSecurity v3 Affected By DoS (Severity HIGH)
The OWASP ModSecurity Core Rule Set (CRS) team has identified a Denial of Service vulnerability in the underlying ModSecurity engine. This affects all releases in the ModSecurity v3 release line. The vendor Trustwave Spiderlabs did not release an update yet. However, we are providing users with a patch for ModSecurity and a workaround if they can not patch. Likewise, we are coordinating the patching with the Linux distributors. This blog post tries to give you a comprehensive overview of the problem with all the resources you need to cope with the situation.
CVE-2019-19886 - HIGH - DoS against libModSecurity 3
The ModSecurity 3.0.x release line suffers from a Denial of Service vulnerability after triggering a segmentation fault on the webserver when parsing a malformed cookie header. All users of ModSecurity 3.0.0 - 3.0.3 should update to ModSecurity 3.0.4 as soon as possible. ModSecurity 2.x is not affected. The CVSS score for the vulnerability is 7.5 (HIGH). MITRE lists the vulnerability as CVE-2019-19886 (but as of this writing, it is only reserved). The OWASP ModSecurity Core Rule Set (CRS) project makes heavy use of unit tests. One of the goals is making sure that all our rules behave as intended on the underlying ModSecurity engine. ModSecurity 2.9 on Apache is our reference platform that passes our expanding list of over 2300 tests.
Core Rule Set Project Won a German OSBAR Award!
The OWASP ModSecurity Core Rule Set Project is very excited about winning one of the OSBAR awards of the German Open Source Business Alliance. The prize is awarded to projects, start-ups and outstanding ideas from the open source environment. The increased attention should make it easier for the award winners to attract users, developers and supporters. CRS hackers Christian Folini and Franziska Bühler with the OSBAR award trophy (photo Fridolin Zurlinden)
The Top 5 Ways CRS Can Help You Fight the OWASP Top 10
The new edition OWASP Top Ten list mentions ModSecurity and the OWASP ModSecurity Core Rule Set for the first time. Let me explain you what the Core Rule Set does and how it can help you protect your services from these risks. The CRS - short for OWASP ModSecurity Core Rule Set - is a set of generic attack detection rules. They are meant for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks with a minimum of false alerts. The Core Rule Set is thus meant as a 1st line of defense against web application attacks as described by the OWASP Top Ten.