{"action":"opened","issue":{"url":"https://api.github.com/repos/SpiderLabs/owasp-modsecurity-crs/issues/527","repository_url":"https://api.github.com/repos/SpiderLabs/owasp-modsecurity-crs","labels_url":"https://api.github.com/repos/SpiderLabs/owasp-modsecurity-crs/issues/527/labels{/name}","comments_url":"https://api.github.com/repos/SpiderLabs/owasp-modsecurity-crs/issues/527/comments","events_url":"https://api.github.com/repos/SpiderLabs/owasp-modsecurity-crs/issues/527/events","html_url":"https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/527","id":171008700,"number":527,"title":"Policy for handling app specific FPs","user":{"login":"lifeforms","id":3464056,"avatar_url":"https://avatars.githubusercontent.com/u/3464056?v=3","gravatar_id":"","url":"https://api.github.com/users/lifeforms","html_url":"https://github.com/lifeforms","followers_url":"https://api.github.com/users/lifeforms/followers","following_url":"https://api.github.com/users/lifeforms/following{/other_user}","gists_url":"https://api.github.com/users/lifeforms/gists{/gist_id}","starred_url":"https://api.github.com/users/lifeforms/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lifeforms/subscriptions","organizations_url":"https://api.github.com/users/lifeforms/orgs","repos_url":"https://api.github.com/users/lifeforms/repos","events_url":"https://api.github.com/users/lifeforms/events{/privacy}","received_events_url":"https://api.github.com/users/lifeforms/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-08-13T13:20:56Z","updated_at":"2016-08-13T13:20:56Z","closed_at":null,"body":"Before we go chasing large numbers of FPs, we have to think up a unified policy to handle application specific FPs.\r\n\r\nAs for timing, there's something to doing a \"tick-tock\" cadence of improving detection in RC1 and then doing a grind of FP reduction during RC2. I'm happy to look at every FP report in detail during RC2, but our time is limited. So I want to spend most effort on the big picture and the least time on workarounds.\r\n\r\nI 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 rules for these applications would in my opinion be laborious, and add lots of complexity to the rules which is hard to untangle later.\r\n\r\nFor instance, in #517 an overbroad regexp 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.\r\n\r\nTo completely make the Drupal CRS editing usable in the default configuration, 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 curated API endpoints and ARGS. \r\n\r\nKeeping app specific exclusion files would be especially attractive if common parameters like `ajax_html_ids[]` get blocked by multiple rules, which based on my 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 rules involved with certain well-known application parameters like `ajax_html_ids[]`.\r\n\r\nIt's also harder for exclusion rules to introduce bugs or bypasses in unrelated APIs. Instead of patching up tens of rules against Drupal `ARGS:ajax_html_ids[]`, or Mediawiki's `/index.php` with `ARGS:wpTextBox1`, or WordPress' post fields, I think we will save huge amounts of development time, testing time, and base rule complexity by just excluding those specific URL+parameter combinations in separate exclusion rules. (If you want to be very specific, you'll need multiple chains to check the URI, ARGS etc. otherwise you will exclude `ajax_html_ids[]` for all kinds of APIs. This arg name is very specific, but what about an FP in `id` or `name` parameter which we'll get some time?)\r\n\r\nFinally it's easier to create and maintain exclusion rules. It's basically like running production and adding exclusions, which we'll have to do anyway on our projects; we'd just share those exclusions with the world. Also, people not desiring those exclusions might remove the exclusions by tag, which is impossible if we patch the base rules.\r\n\r\nSo 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.\r\n\r\nSo my first proposal would be:\r\n\r\n- RC1 focus on adding detection (which we have done)\r\n- RC2 focus on FP (which considered the new issues created seems to be the case)\r\n- Consider application specific exclusion files (eg. Drupal, WordPress, Mediawiki) rather than patching up rules\r\n\r\nComment, rate, and subscribe!"}}
{"actor":{"display_login":"lifeforms"}}