Dauto (and Christian),
I had a look at this rule before and am not a fan.
CSRF_TOKEN's should come from the app in my mind and not the WAF. However
ModSecurity does have a method of using them, which is an interesting proof of
concept, but I think it's flaky for a number of reasons.
The way it works is it uses collections to store the CSRF_TOKEN. Rule 981145
uses content injection to inject a bit of Javascript to set the CSRF token on
any URLs or forms for any HTML pages requested and when the subsequent request
comes in after rule 981144 compares the CSRF_TOKEN in the collection and
rejects any requests without a valid token. The below rule is firing because it
didn't match.
It's an interesting idea, and would work in certain scenarios, but I can see
multiple issues with it. For a start when first turning it on none of the
current messages will have CSRF tokens so need to think about how to deploy,
and the content injection concept has multiple issues in my mind, but for me
the biggest issues is with collections.
Collections is, IMHO, one of the weak points of ModSecurity. As soon as you get
any volume of traffic Modsecurity struggles to cope with the file based SDBM
format it uses to hold collections. I (and lots of others) see multiple issues
with managing collections, from alerts like "collections_remove_stale: Failed
deleting collection" to collections growing massively in size unless
periodically deleted, to collections not working across multiple instances of
Apache/ModSecurity without a complicated sharing mechanism...etc.
Maybe this will be improved in ModSecurity v3 which might have memcache based
collections rather than disk based collections but for now, collections cannot
really be relied upon in my view (though others may disagree). They are fine
(just!) for rate limiting (where missing an odd update or read of collection
doesn't matter too much as, in worst case you just don't block until a little
later), but cannot be used when you need to reply on them. And CSRF_TOKEN's
need to reply on them or they reject messages. Hoping it is fixed in v3 as
reliable collections open up a wealth of opportunities like this CSRF
implementation (though still wouldn't recommend it for CSRF for other reasons
mentioned briefly above).
Anyway for now I don't recommend using this (or most of the optional rules to
be honest).
Thanks,Barry
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
