[Owasp-modsecurity-core-rule-set] Review of CRS 2.0.3

Ryan Barnett ryan.barnett at breach.com
Wed Dec 2 11:58:15 EST 2009

On Wednesday 02 December 2009 05:09:31 am Ivan Ristic wrote:
> Hi,
> I was on a plane a couple of weeks ago, with nothing better to do, so
> I took the opportunity to review the Core Rule Set, as bundled with
> ModSecurity 2.5.11. It is by no means a comprehensive review, but
> perhaps I will make another pass at some point in the future.
> Here are my observations:
> - Why are there two scripts to interface to ClamAV (in the ModSecurity
> distribution)? Any why are they under the rules/ folder, instead in
> tools/ -- they can be useful with custom rules too.
>   - Thanks for the mention of Apache Security. I have a book about
> ModSecurity itself coming up ;)
>   - Reading the installation instructions: I don’t think that rule
> sets should have anything to do with ModSecurity configuration. They
> just make automated updates impossible. ModSecurity itself should have
> a default configuration file and leave it to the users to customise
> it.
>   - Google Analytics: The requirement to disable the rules in order to
> support Google Analytics activation makes the rules a no-go in virtual
> hosting environments.
>   - About Regular Expressions: The optimisation of regular expressions
> should be moved into ModSecurity and made transparent for users.
>   - There’s no mention of the optional rules folder; what are those for?
> - In modsecurity_crs_20_protocol_violations.conf
>   - Typo in the header: "ModSecuirty".
>   - There's a TODO entry right below the header, but there are no
> instructions to do anything.
>   - The rules that check for request body processor errors should not
> be here. They should be part of ModSecurity configuration instead.
>   - 960012: There is no real reason for ModSecurity 2.x to request
> POST request to have C-L.
>   - 960013: “ModSecurity does not support chunked transfer encodings
> at this time.” – this is incorrect.
>   - Many of these rules may or may not be doing the right thing, but I
> have no way to validate what they are doing. I know I am asking for a
> lot, but each rule should provide some reasoning that would help the
> users understand why it is important. For example, rule 960021 does
> not allow the Expect header to be used with HTTP/1.0 because it is an
> HTTP/1.1 feature. But why should you care? Is there a way to abuse the
> header in combination with HTTP/1.0?
>   - The “# Check UTF enconding” (sic) does not have an ID. Further, it
> makes a global change, which affects all sites and all applications on
> the server.
>   - Rule 950801:
>     - What is utf-8 is used on one script (page) on a site, but not in
> another? How will this rule handle it?
>     - Request headers never use utf-8 anyway (although you may get
> utf-8 in User-Agent or Referer, as you know).
>     - Request URIs allow for utf-8 in a general case, even when
> applications use something else.
>     - I think you only need to check ARGS here.
>     - Rule 950116: Can the %u encoding really be used in request
> headers? And in XML payloads?
> - In crs_21:
>   - If I must patch mod_unique_id to make a rule work, shouldn’t that
> rule be disabled by default?
> - In crs_23:
>   - Apache limits shouldn’t be here. That too is part of someone's
> configuration.
> - In crs_30:
>   - ModSecurity does support compressed content. It's true that there
> were some problems with getting mod_deflate to run after ModSecurity,
> but that should have been fixed.
> - In crs_35:
>   - Why not use parallel matching to discover bad user agents? It
> would be easier to understand and maintain.
> - In crs_40:
>   - The HTTP Parameter Pollution rule does not have an ID. It’s very
> creative in how it uses the rule language, but it warns on any
> parameter that occurs more than once (and that is entirely
> legitimate).
>   - Why does rule 950907 use t:htmlEntityDecode? I would imagine that
> transformation is only for attacks against a HTML surface. (The
> question applies to many other rules. I also think t:urlDecodeUni is
> used too liberally.
>   - I see that the rules use “block”, which is good, but they also use
> “status:400”. Why?
>   - It would be nice if you could explain how the transaction
> variables are used for anomaly scoring and keeping the information on
> matched variables around. It takes some deciphering to understand
> what’s going on.
>   - All the rules use tx.msg—won’t the messages overwrite one another?
> That would make the messages emitted from crs_49 inconsistent.
> You can tell from the review that I gave up looking into individual
> rules at some point. With no documentation in the rules themselves,
> the review would have taken days. After my review I have a sense that
> the CRS has tremendous value (and an enormous improvement over the
> previous version), but that it does not explain what it does. As such,
> I can only treat the rules as a black box and hope for the best. The
> final verdict to the usefulness can come only from someone using the
> rules in production.

Outstanding feedback Ivan!  I agree with your final conclusion and I believe 
that the right course of action is to utilize the OWASP CRS project site for 
the full documentation.  I am planning to update the site with this info... 
when I have time....  Once I start documenting these items, I will ping the 
mail-list so everyone can review, comment and hopefully, join in and replicate 
the process and document stuff themselves.


More information about the Owasp-modsecurity-core-rule-set mailing list