LFI path traversal rules using REQUEST_BODY cannot be excluded

_Issue originally created by user lifeforms on date 2016-10-02 10:24:28. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/597._

I’m tuning for WordPress FP right now, and I want to exclude some fields. For instance, I’d like to allow people to use the ../ sequence (LFI, rule 930110) in a password field.

However, it’s currently impossible for me to exclude this LFI check from a parameter. Normally I would do ctl:ruleRemoveTargetByTag=CRS;ARGS:passwd to exclude the parameter passwd from all our rules.

But rule 930110 is still firing on ../ in a password string. The reason is that rule 930110 is not checking ARGS, but instead it is checking the following variables instead:

REQUEST_URI_RAW|REQUEST_BODY|REQUEST_HEADERS|XML:/*

This makes it impossible to selectively exclude this rule for a single query parameter, unless I want to remove the whole REQUEST_BODY target which I’d prefer not to do.

The raw uri/body check is rather rare in the CRS; rule 930100 also has it. I think I can see why the body is checked – an unencoded post body (stdin) is often used for code injection, plus perhaps it could have a performance advantage over scanning the args. I see that the commit, 0a035ccb, was made in 2014 by Ryan. Do you recall why this approach was taken rcbarnett? (If you have time to look at it!)

I think a body payload should turn up in ARGS_NAMES as well, so we could probably switch the rule’s variables over without losing detection. But I’d want to add a lot of tests for it. Realistically it might probably be too late for 3.0, although I could see more people hitting this problem.

[CRS-migration-bot]

User dune73 commented on date 2020-02-11 13:56:35:

emphazer volunteered to take on this issue as he has been affected before. This is likely to take until March 2020 though.

Meeting minutes: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1671#issuecomment-584320407

[CRS-migration-bot]

User mhoran commented on date 2019-05-05 13:47:35:

I just hit this after enabling modsecurity and the CRS for my WordPress site. I had a draft post that had a sentence ending in “…”. Of course, the thing that comes after “…” is a newline, or “\n” – which triggers rule 930110 and 942440. The WordPress exclusions don’t do anything to handle this, so I couldn’t save my post. I deleted it and recreated without the “…”, but fortunately I had access to the modsecurity audit log otherwise I would have had no idea what was happening.