[Owasp-modsecurity-core-rule-set] CSRF Attack Detected - Invalid Token

[Dauto Jeichande]

Dear all,
IŽm testing the modsecurity_crs_43_csrf_protection.conf. I can see that the requests to the application contains the CSRF Token. However in the error.log I'm having the following warning when browsing the application:
ModSecurity: Warning. Match of "streq %{SESSION.CSRF_TOKEN}" against "ARGS:CSRF_TOKEN" required. [file "/usr/local/apache/conf/crs/activated_rules/modsecurity_crs_43_csrf_protection.conf"] [line "34"] [id "981144"] [msg "CSRF Attack Detected - Invalid Token."] [hostname "xxxxx"] [uri "xxxxxx"] [unique_id "xxxxxxxxxxxxxx"]
What should I do to fix this warning.
Thanks,
Dauto

-

[Christian Folini]

Dauto,

As you know, this is part of the optional rules collection and this
means it is less used and less tested then the other core rules.

Personally, I have not used this ruleset, so I am not really sure it
works as advertised.

A few questions, I would try to answer if I was debugging this?
- Is the 16 session hijacking ruleset enabled?
- Are you sure it is executed before the 43 csrf file (I guess it is)
- Is the session collection active at the moment 981144 is exctivated?
- Do you see any values in the session collection?
- Can you write and read from the session collection?

Ahoj,

Christian

On Thu, May 12, 2016 at 12:08:47AM +0200, Dauto Jeichande wrote:
> Dear all,
> I´m testing the modsecurity_crs_43_csrf_protection.conf. I can see that the requests to the application contains the CSRF Token. However in the error.log I'm having the following warning when browsing the application:
> ModSecurity: Warning. Match of "streq %{SESSION.CSRF_TOKEN}" against "ARGS:CSRF_TOKEN" required. [file "/usr/local/apache/conf/crs/activated_rules/modsecurity_crs_43_csrf_protection.conf"] [line "34"] [id "981144"] [msg "CSRF Attack Detected - Invalid Token."] [hostname "xxxxx"] [uri "xxxxxx"] [unique_id "xxxxxxxxxxxxxx"]
> What should I do to fix this warning.
> Thanks,
> Dauto
>
> -

> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-***@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set


--
mailto:***@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini

[Dauto Jeichande]

Hi Christian,
Thank you for your replay. I will use your feedback to investigate the reason, but will postpone to another time. From my research I found also that this rule is not much used and need some extra efforts to put it working on specific application.
Regards,
Dauto

> Date: Thu, 12 May 2016 09:13:14 +0200
> From: ***@netnea.com
> To: ***@hotmail.com
> CC: owasp-modsecurity-core-rule-***@lists.owasp.org
> Subject: Re: [Owasp-modsecurity-core-rule-set] CSRF Attack Detected - Invalid Token
>
> Dauto,
>
> As you know, this is part of the optional rules collection and this
> means it is less used and less tested then the other core rules.
>
> Personally, I have not used this ruleset, so I am not really sure it
> works as advertised.
>
> A few questions, I would try to answer if I was debugging this?
> - Is the 16 session hijacking ruleset enabled?
> - Are you sure it is executed before the 43 csrf file (I guess it is)
> - Is the session collection active at the moment 981144 is exctivated?
> - Do you see any values in the session collection?
> - Can you write and read from the session collection?
>
> Ahoj,
>
> Christian
>
> On Thu, May 12, 2016 at 12:08:47AM +0200, Dauto Jeichande wrote:
> > Dear all,
> > IŽm testing the modsecurity_crs_43_csrf_protection.conf. I can see that the requests to the application contains the CSRF Token. However in the error.log I'm having the following warning when browsing the application:
> > ModSecurity: Warning. Match of "streq %{SESSION.CSRF_TOKEN}" against "ARGS:CSRF_TOKEN" required. [file "/usr/local/apache/conf/crs/activated_rules/modsecurity_crs_43_csrf_protection.conf"] [line "34"] [id "981144"] [msg "CSRF Attack Detected - Invalid Token."] [hostname "xxxxx"] [uri "xxxxxx"] [unique_id "xxxxxxxxxxxxxx"]
> > What should I do to fix this warning.
> > Thanks,
> > Dauto
> >
> > -
>
> > _______________________________________________
> > Owasp-modsecurity-core-rule-set mailing list
> > Owasp-modsecurity-core-rule-***@lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
>
>
> --
> mailto:***@netnea.com
> http://www.christian-folini.ch
> twitter: @ChrFolini

[Barry Pollard]

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

[Christian Folini]

Barry,

On Thu, May 12, 2016 at 10:01:53AM +0100, Barry Pollard wrote:
> 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.

Thank you for sharing your experience / observations. This was exactly
my impression of this rule as well.

I have sites in production that use persistent collections and
prepend/append constructs. But the scope is very limited and none
is high traffic.

So yes, this can be made to work, but it's a road that is rarely
travelled. It's kind of adventurous.

Ahoj,

Christian

--
If you have men who will only come if they know there is a good road,
I don't want them. I want men who will come if there is no road at all.
-- David Livingstone

[Ryan Barnett]

Hey everyone,
Thought I would come "out the shadows" and comment on this topic since I was the one who created those CSRF rules -
These are definitely PoC level rules. They were intended to show ModSecurity’s content injection capabilities and this was just one use-case.
The actual JS code that is injected (https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/optional_rules/modsecurity_crs_43_csrf_protection.conf#L42-L107) is adapted from the older OWASP CSRFGuard code and it has limitations in its ability to properly modify all DOM elements to add the CSRF token. There is newer code available for that project that addresses some of these limitations - https://github.com/esheri3/OWASP-CSRFGuard/blob/master/csrfguard/src/main/resources/csrfguard.js
If you want to still try and use this – you probably want to modify which URLs are enforcing this logic as currently it is matching all - https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/optional_rules/modsecurity_crs_43_csrf_protection.conf#L30
In addition to also requiring that the session hijacking conf file is activated - https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/optional_rules/modsecurity_crs_16_session_hijacking.conf#L44-L45 – you also should activate the Ignore Static Content conf file so that you aren’t triggering alerts for request to static image files, etc.. - https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/optional_rules/modsecurity_crs_10_ignore_static.conf
You might also want to try to use the @rsub approach mentioned at the bottom of this blog post - https://www.trustwave.com/Resources/SpiderLabs-Blog/Detecting-Malice-with-ModSecurity--(Updated)-CSRF-Attacks/. This will modify the FORM HTML and inject the token directly into it vs. appending a bunch of JS and then having it modify the DOM.
Now, if I were to try to tackle CSRF today in ModSecurity, I would use the RSUB approach (above) along with JS append to implement the Double-Submit Cookie anti-CSRF approach - http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html. The advantage to this approach is that it is “stateless” meaning that you won’t have to use ModSecurity’s SDBM persistent storage. If you are injecting the same anti-CSRF token value as BOTH a hidden FORM param and as a new Cookie value then all ModSecurity WAF has to do is make sure that URLs that you want to protect (e.g. - POST requests to URL /checkout, etc
) have BOTH the CSRF param and cookie and that they BOTH match each other.
One last comment – Perfection is the Enemy of Good. While anti-CSRF tokens are sexy don’t sleep on good old Referer Enforcement checks. If you have a workflow that follows a strict path and you want to prevent CSRF attacks, you can simply craft up some SecRules that check the Method + URL + Referer(s) and block ones that are: 1) Missing Referer, 2) Coming from off-domain, or 3) Not coming from your on-domain approved Referer page list.
Hope this info helps.
Ryan


From: <owasp-modsecurity-core-rule-set-***@lists.owasp.org> on behalf of Christian Folini <***@netnea.com>
Date: Thursday, May 12, 2016 at 5:20 AM
To: Barry Pollard <***@hotmail.com>
Cc: "owasp-modsecurity-core-rule-***@lists.owasp.org" <owasp-modsecurity-core-rule-***@lists.owasp.org>
Subject: Re: [Owasp-modsecurity-core-rule-set] CSRF Attack Detected - Invalid Token

Barry,

On Thu, May 12, 2016 at 10:01:53AM +0100, Barry Pollard wrote:
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.

Thank you for sharing your experience / observations. This was exactly
my impression of this rule as well.

I have sites in production that use persistent collections and
prepend/append constructs. But the scope is very limited and none
is high traffic.

So yes, this can be made to work, but it's a road that is rarely
travelled. It's kind of adventurous.

Ahoj,

Christian

--
If you have men who will only come if they know there is a good road,
I don't want them. I want men who will come if there is no road at all.
-- David Livingstone