[Owasp-modsecurity-core-rule-set] Review of CRS 2.0.3
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:
> 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.
> - In README
> - 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
> - 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
> - 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
> - 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