From d537dcf1b82866f0c05d9c553f18d5a9087d266e Mon Sep 17 00:00:00 2001 From: TW - Vincent <315173+touchweb-vincent@users.noreply.github.com> Date: Tue, 4 Nov 2025 08:31:35 +0100 Subject: [PATCH 1/5] Update 2-3-false-positives-and-tuning.md --- .../2-3-false-positives-and-tuning.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md index adbcefee..72288344 100644 --- a/content/2-how-crs-works/2-3-false-positives-and-tuning.md +++ b/content/2-how-crs-works/2-3-false-positives-and-tuning.md @@ -221,6 +221,11 @@ SecRuleRemoveById 933151 **Scenario:** Several different parts of a web application are causing false positives with various SQL injection rules. None of the web services behind the WAF make use of SQL, so it is deemed safe to tune away these false positives by removing all the SQLi detection rules. +{{% notice warning %}} +This type of broad exclusion must be avoided at all costs for most standard web application use cases. +In such contexts, you must never do this. +{{% /notice %}} + **Rule Exclusion:** ```apache @@ -241,6 +246,11 @@ SecRuleRemoveByTag attack-sqli SecRuleUpdateTargetById 941320 "!ARGS:wp_post" ``` +{{% notice %}} +If, for optimization purposes, you need to use dynamic variables - for example, to efficiently filter Base64 variants - be aware that this directive supports dynamic variables, like so: +`SecRuleUpdateTargetById 1 "!TX:/^base64_ARGS:ttcsid_[\w]+$/"` +{{% /notice %}} + #### Example 4 *(SecRuleUpdateTargetByTag)* *(Configure-time RE. Exclude specific variable from rule.)* @@ -300,7 +310,7 @@ SecRule REQUEST_URI "@beginsWith /web_app_1/content" \ ```apache # CRS Rule Exclusion: 941150 - XSS Filter - Category 5: Disallowed HTML Attributes -SecRule REQUEST_URI "@beginsWith /dynamic/new_post" \ +SecRule REQUEST_URI "@rx ^/dynamic/new_post" \ "id:1020,\ phase:1,\ pass,\ @@ -314,6 +324,11 @@ SecRule REQUEST_URI "@beginsWith /dynamic/new_post" \ **Scenario:** The values of request cookie 'uid' are causing false positives with various SQL injection rules when trying to log in to a web service at location '/webapp/login.html'. It is decided that it is not a risk to allow SQL-like content in this specific cookie's values for the login page, however it is deemed unacceptable to disable the SQLi detection rules for anything apart from the specific request cookie in question at the login page only. It is decided to tune away these false positives by excluding only the problematic request cookie from the SQLi detection rules, and only when accessing '/webapp/login.html'. +{{% notice warning %}} +This type of broad exclusion must be avoided at all costs for most standard web application use cases. +In such contexts, you should never do this. +{{% /notice %}} + **Rule Exclusion:** ```apache From 1e2cc983403011f1e9beaead5e906779ec1fa812 Mon Sep 17 00:00:00 2001 From: TW - Vincent <315173+touchweb-vincent@users.noreply.github.com> Date: Thu, 6 Nov 2025 11:21:20 +0100 Subject: [PATCH 2/5] Update content/2-how-crs-works/2-3-false-positives-and-tuning.md Co-authored-by: Ervin Hegedus --- content/2-how-crs-works/2-3-false-positives-and-tuning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md index 72288344..713dfa8d 100644 --- a/content/2-how-crs-works/2-3-false-positives-and-tuning.md +++ b/content/2-how-crs-works/2-3-false-positives-and-tuning.md @@ -247,7 +247,7 @@ SecRuleUpdateTargetById 941320 "!ARGS:wp_post" ``` {{% notice %}} -If, for optimization purposes, you need to use dynamic variables - for example, to efficiently filter Base64 variants - be aware that this directive supports dynamic variables, like so: +If you need to use dynamic variables for optimization purposes - for example, to effectively filter Base64 variants - note that this policy supports dynamic variables, for example: `SecRuleUpdateTargetById 1 "!TX:/^base64_ARGS:ttcsid_[\w]+$/"` {{% /notice %}} From a50a3dd7bc39e0756fa801b8dd5be52346b41c13 Mon Sep 17 00:00:00 2001 From: TW - Vincent <315173+touchweb-vincent@users.noreply.github.com> Date: Thu, 6 Nov 2025 11:24:30 +0100 Subject: [PATCH 3/5] Update content/2-how-crs-works/2-3-false-positives-and-tuning.md Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com> --- content/2-how-crs-works/2-3-false-positives-and-tuning.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md index 713dfa8d..5c64cd8d 100644 --- a/content/2-how-crs-works/2-3-false-positives-and-tuning.md +++ b/content/2-how-crs-works/2-3-false-positives-and-tuning.md @@ -222,8 +222,9 @@ SecRuleRemoveById 933151 **Scenario:** Several different parts of a web application are causing false positives with various SQL injection rules. None of the web services behind the WAF make use of SQL, so it is deemed safe to tune away these false positives by removing all the SQLi detection rules. {{% notice warning %}} -This type of broad exclusion must be avoided at all costs for most standard web application use cases. -In such contexts, you must never do this. +This type of broad exclusion is dangerous and should only be considered if the rules are causing problems _and_ the application is not vulnerable to the specific attack, e.g., the PHP rules cause issues and no application behind the WAF uses PHP. + +In general, the less exclusions the better, since every rule reduces the amount of bad traffic arriving at the protected application. {{% /notice %}} **Rule Exclusion:** From abc9b669efba185c1dfbf40f3ce40776085e72bc Mon Sep 17 00:00:00 2001 From: TW - Vincent <315173+touchweb-vincent@users.noreply.github.com> Date: Sun, 9 Nov 2025 20:15:31 +0100 Subject: [PATCH 4/5] Update 2-3-false-positives-and-tuning.md --- content/2-how-crs-works/2-3-false-positives-and-tuning.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md index 5c64cd8d..c44b0b4b 100644 --- a/content/2-how-crs-works/2-3-false-positives-and-tuning.md +++ b/content/2-how-crs-works/2-3-false-positives-and-tuning.md @@ -326,8 +326,7 @@ SecRule REQUEST_URI "@rx ^/dynamic/new_post" \ **Scenario:** The values of request cookie 'uid' are causing false positives with various SQL injection rules when trying to log in to a web service at location '/webapp/login.html'. It is decided that it is not a risk to allow SQL-like content in this specific cookie's values for the login page, however it is deemed unacceptable to disable the SQLi detection rules for anything apart from the specific request cookie in question at the login page only. It is decided to tune away these false positives by excluding only the problematic request cookie from the SQLi detection rules, and only when accessing '/webapp/login.html'. {{% notice warning %}} -This type of broad exclusion must be avoided at all costs for most standard web application use cases. -In such contexts, you should never do this. +This type of broad exclusion is dangerous. Even though the decision in this example may seem trivial, rule exclusions always carry a risk. It is important to understand the risk of disabling a rule, i.e., which attack vectors become available by disabling the rule, even if only a single target is affected. {{% /notice %}} **Rule Exclusion:** From 8917b90b4fd3f979fdca1c9ec17afdf260c06ecf Mon Sep 17 00:00:00 2001 From: TW - Vincent <315173+touchweb-vincent@users.noreply.github.com> Date: Mon, 10 Nov 2025 17:46:57 +0100 Subject: [PATCH 5/5] Update 2-3-false-positives-and-tuning.md --- content/2-how-crs-works/2-3-false-positives-and-tuning.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md index c44b0b4b..adbebc9f 100644 --- a/content/2-how-crs-works/2-3-false-positives-and-tuning.md +++ b/content/2-how-crs-works/2-3-false-positives-and-tuning.md @@ -247,11 +247,6 @@ SecRuleRemoveByTag attack-sqli SecRuleUpdateTargetById 941320 "!ARGS:wp_post" ``` -{{% notice %}} -If you need to use dynamic variables for optimization purposes - for example, to effectively filter Base64 variants - note that this policy supports dynamic variables, for example: -`SecRuleUpdateTargetById 1 "!TX:/^base64_ARGS:ttcsid_[\w]+$/"` -{{% /notice %}} - #### Example 4 *(SecRuleUpdateTargetByTag)* *(Configure-time RE. Exclude specific variable from rule.)*