This is the CRS newsletter covering the period from Early January until today.
We held our monthly community chat. We had quite a few people stop by.
csanders
airween
franbuehler
lifeforms
spartantri
dune73
allanbo
Our agenda from before the chat is available here. During the chat we discussed the following:
Issue #989 status: Currently waiting on canders to fix Dockerfile before it can merged. The Dockerfile’s point to csanders-git’s personal repository instead of CRS repo. This is done in error. csanders will change config default for docker to build on ubuntu and not fedora.
This is the CRS newsletter covering the period from Early December until today (Now in 2018, Happy New Year!!).
We held our monthly community chat. We had quite a few people stop by. Special thanks to lifeforms for leading the chat.
csanders
fzipi
spartantri
dune73
emphazer
fgs
franbuehler
Our agenda from before the chat is available here. We had a short chat, during the chat we discussed the following:
The OWASP CRS Mailing list seemed to be broken for a bit, we confirmed that it is currently working, and who the administrators are (dune73, lifeforms, and csanders)
csanders committed to making changes to FTW necessary to get azhao155’s PR’s (and #989 which deals with FTW) merged.
A number of folks are testing the Java protections PR that is slotted for 3.1
The Java rules (#990), that are a key feature of 3.1 need some attention
We’d like to see correct formatting before merger
And a number of FTW tests added for it.
There was interest expressed in a format checker script
Dune73 will review #983 and #982 and merge if ready.
csanders will write some of the documentation from #986 and provide a space on coreruleset.org for the information to live.
#974, which deals with transfer encoding, is awaiting PR, this change requires both correctly evaluating the TE RFC and the extensions. For 3.1 we’re gonna do basic abuse checks in PL and any extension checks will be in PL minimum with further review planed for 3.2.
We’d like to add the PR for CPanel exclusion to 3.1, due to how CPanel sets up their system it causes false positives, ideally CPanel would fix this but they haven’t yet so we’ll add a class exclusion similar to how we did with WordPress, Drupal, etc. emphazer said he could take this on.
We reviewed spartantri idea for filetype checking based on STREAM_INPUT_BODY. It is unclear if this feature will be exposed as part of libmodsecurity. A PR will be prepared with the known compatible stuff enabled and the other stuff commented out and possible enabled over time.
Dune73 discussed a project for a volunteer that would shift rules that only require Phase 1 variables to use the phase:1 action for performance reasons.
AppSecEU has been moved from Israel to UK and shifted to match the dev summit two weeks earlier. This would thus be perfect for our planned little CRS summit. @dune73 is in charge of this.
dune73 is doing a ModSec/CRS/NGINX webinar with O’Reilly on January 9. Subscription is free, the slides will be shared afterwards.
The next community chats will be held on the following dates:
Let me put one thing straight: there are two things when we talk about ModSecurity. There is the naked ModSecurity engine running inside NGINX or Apache and there is the rule set that instructs the engine what to do. Many different rule sets exist. But the rule set with the largest user base (and longest name) is the OWASP ModSecurity Core Rule Set or CRS for short.
Back in August and September, Chaim Sanders introducedFTW, a Framework to Test WAFs via two blost posts. Existing unit testing frameworks are not really suitable for this purpose as they do not grant you enough control over the requests and the ability to look at the WAF log that needs to be bolted on. Chaim teamed with Zack Allen and Christian Peron from Fastly to create this. So FTW was developed with exactly our use case in mind. Time to really understand this and to start using it.
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.
Additional trainings in Spring are likely to happen in Geneva and Amsterdam (on popular request).
Additionally, teacher Christian Folini, will also be holding a ModSecurity on NGINX Webinar with O’Reilly on January 9. The subscription is no yet online, but will be announced shortly (I plan to update this blog post with the link as soon as it is available).
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.
I would like to explain my work disassembling highly optimized regular expressions. A project like this might discourage many people, but to me, it is very exciting work! I like this kind of investigative work and want to explain what, exactly, I did, why I did it and how!
What’s the problem?
The SQLi rules in the core rule set consist of 43 rules. 25 of them have been optimized with the Perl module Regexp::Assemble. This module assembles multiple regular expressions into one regular expression. The source patterns were lost over the years as they were taken from the old CRS project and partly from other projects, and source code management migrations led to the situation we are facing now. Unfortunately, there is no tool for disassembling an optimized regex, so we did not have a chance to undo this optimization process and regain the original patterns.