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-boun...@lists.owasp.org> on behalf of Christian Folini <christian.fol...@netnea.com> Date: Thursday, May 12, 2016 at 5:20 AM To: Barry Pollard <barry_poll...@hotmail.com> Cc: "owasp-modsecurity-core-rule-set@lists.owasp.org" <owasp-modsecurity-core-rule-set@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 _______________________________________________ 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
_______________________________________________ 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
