Policy for handling app specific FPs

_Issue originally created by user lifeforms on date 2016-08-13 13:20:56. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/527._

Before we go chasing large numbers of FPs, we have to think up a unified policy to handle application specific FPs.

As for timing, there’s something to doing a “tick-tock” cadence of improving detection before RC1 and then doing a grind of FP reduction before RC2. I’m happy to look at every FP report in detail before RC2, but our time is limited. So I want to spend most effort on the big picture and the least time on workarounds.

I would be happy to commit to the goal of having zero FP for common applications like Drupal, though it’s quite a commitment. CMS editor interfaces are very prone to many rule alerts, as people submit various HTML and content. We might not achieve this in a month. But we could get pretty far. However, if we commit to this goal, we need to do it in a very efficient and scalable way. Finetuning CRS rules themselves to exclude parameters for these applications (e.g. with chains) would in my opinion be laborious, and add lots of complexity to the rules which is hard to untangle later.

For instance, in #517 an overbroad pmf rule causes FP in ARGS:ajax_html_ids[] in the Drupal CMS editor interface. We could battle this specific FP in various ways. In the long term though, we will get hundreds of FP reports like this - we know how life was with CRS2 for a small installation, but now we are committing to suppressing them on a global scale.

To completely make CMS editing zero-FP, I think it is a viable long term strategy to start curating an application-specific rule file (ie 9xx-DRUPAL.conf) which would include app specific exclusions on selected API endpoints and ARGS. We could start doing the same for WordPress.

Keeping app specific exclusion files would be especially attractive if common parameters like ajax_html_ids[] get blocked by multiple rules, which based on my Drupal experience with CRS2 I am positive will happen, especially in higher paranoia levels. App specific exclusion rules can be maintained locally but do a broad sweep across many rules and paranoia levels. Especially when running on PL2+ there might be 5-15 attack rules involved with certain well-known application parameters like ajax_html_ids[].

Separate exclusions also prevent base rule complexity. It’s also harder for exclusion rules to introduce bugs or bypasses in unrelated APIs. If we really want to carve out a very specific application FP, you’ll need multiple chains to check the URI, ARGS etc. otherwise you will open up ajax_html_ids[] for all kinds of unrelated APIs. That’s a lot of chains for a single FP type. Now, ajax_html_ids[] is a very specific arg name and might not cause bypass in any other apps, but what about an FP in a more common id or name parameter which we’ll surely get soon?

Finally it’s easier to create exclusion rules. It’s basically like running production and fixing FPs locally, which we’ll have to do anyway on our projects; we’d just share those exclusions with the world. The barrier to maintain them will therefore also be lower for a CRS user when compared to hacking on a CRS attack rule itself. So exclusions may invite more contributions.

Also, people not desiring app specific exclusions might remove the exclusions by tag, which is impossible if we patch the attack rules in-place.

So it seems to me a productive activity to say, okay, we explicitly decide to be able to do CMS editing, wiki editing, in the default configuration with near-zero FP, then our best option in the general case is probably to start some app specific exclusion rule sets.

So my first proposal would be:

• RC1 focus on adding detection (which we have done)
• RC2 focus on FP (which considered the new issues created seems to be the case)
• Consider application specific exclusion files (eg. Drupal, WordPress, Mediawiki) rather than patching up rules

Comment, rate, and subscribe!

[CRS-migration-bot]

User dune73 commented on date 2016-09-11 04:25:18:

lifeforms : I was wrong about macro expansion with @rx. It is supported. Recently read that it was not, did not check and now I do not longer remember where I read it.

[CRS-migration-bot]

User lifeforms commented on date 2016-09-21 20:01:02:

Decided on IRC:

• Yes, do app exclusions
• Start with WordPress, Drupal
• Make an on/off switch per app
• Don’t use global flag
• Don’t filter on paths (either using regexp or beginsWith) - regexp would be complex to configure and probably an advanced feature; strings don’t offer much advantage over the user using SecRule to selectively enable exclusions if wanted.