Open jcchavezs opened 1 year ago
This issue is stale because it has been open for 30 days with no activity.
Can't wait to see the feature ! I have so much trouble to deal with false positive rule when ARGS look like this : ARGS:json.login.uris.0.uri ARGS:json.login.uris.1.uri ARGS:json.passwordHistory.2.password ARGS:json.passwordHistory.1.password ARGS:json.passwordHistory.0.password etc...
Are you up to work out such change? If not, would you come up with a unit test with meaningful cases?
On Sun, 13 Aug 2023, 18:45 Barnoux, @.***> wrote:
Can't wait to see the feature ! I have so much trouble to deal with false positive rule when ARGS look like this : ARGS:json.login.uris.0.uri ARGS:json.login.uris.1.uri ARGS:json.passwordHistory.2.password ARGS:json.passwordHistory.1.password ARGS:json.passwordHistory.0.password etc...
— Reply to this email directly, view it on GitHub https://github.com/corazawaf/coraza/issues/718#issuecomment-1676409272, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXOYASMMS4V354ZWBRT2JTXVEACXANCNFSM6AAAAAAVZDJAMA . You are receiving this because you authored the thread.Message ID: @.***>
Feature will be veeeery appreciated!
Awesome! I wonder if any of you guys could provide example cases so we make sure we aren't implementing an hypothetical feature but more like something you will actually use.
On Thu, 21 Sept 2023, 10:21 flyingman15, @.***> wrote:
Feature will be veeeery appreciated!
— Reply to this email directly, view it on GitHub https://github.com/corazawaf/coraza/issues/718#issuecomment-1729084450, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXOYASDYXKAUKLSNYJFCUDX3P2IVANCNFSM6AAAAAAVZDJAMA . You are receiving this because you authored the thread.Message ID: @.***>
Awesome! I wonder if any of you guys could provide example cases so we make sure we aren't implementing an hypothetical feature but more like something you will actually use. …
Hello, In my case we are receiving a json containing a list or articles with their structure (title, body, url, etc). For each of them we would like to disable a rule only on their title for example. The numbering of arg names we see in ModSec logs seems to imply the only way to handle this would be with regex with ruleRemoveTargetById
Let me dig in my old conf files, because I had some actual use cases.
@jcchavezs I can try to work on a use case with Vaultwarden, but i don't know exactly what you need.
We need to show actual rules that will benefit from this.
Hi, as I enhance the configuration of CRS for the Vaultwarden application, I've encountered a scenario where employing regex for the ctl key, specifically for ARGS, could be beneficial.
In the given example, the alert (ID 932220) is triggered because the ARGS content of json.login.uris.1.uri is encrypted:
{
"level": "error",
"ts": 1705353717.3021958,
"logger": "http.handlers.waf",
"msg": "[client \"192.168.1.1\"] Coraza: Warning. Remote Command Execution: Unix Command Injection with pipe [file \"/ruleset/coreruleset/rulesV4RC2/REQUEST-932-APPLICATION-ATTACK-RCE.conf\"] [line \"0\"] [id \"932220\"] [rev \"\"] [msg \"Remote Command Execution: Unix Command Injection with pipe\"] [data \"Matched Data: =|ufR/HPSS45/Ul found within ARGS:json.login.uris.1.uri: 2.FoU9JIrRUvn6FhRbPmhKTA==|vnSOLkOXuYSRm7tER2zFgHk7dQw1II0v5NcoeCXQHE4=|ufR/HPSS45/UlE7cS1xx1zUSKOSfcL5JMN14uXCsLz4=\"] [severity \"critical\"] [ver \"OWASP_CRS/4.0.0-rc2\"] [maturity \"0\"] [accuracy \"0\"] [tag \"application-multi\"] [tag \"language-shell\"] [tag \"platform-unix\"] [tag \"attack-rce\"] [tag \"paranoia-level/2\"] [tag \"OWASP_CRS\"] [tag \"capec/1000/152/248/88\"] [tag \"PCI/6.5.2\"] [hostname \"\"] [uri \"/api/ciphers\"] [unique_id \"IvajjhfZVMldJlxH\"]\n"
}
When adding an element in the Vault, multiple URLs can be involved, as illustrated in the provided image.
This scenario highlights the need for adding regex for ctl key to facilitate easier whitelisting.
Here's the current whitelist rule under construction:
SecRule REQUEST_METHOD "@streq POST" \
"id:1009,\
phase:1,\
pass,\
log,\
t:none,\
msg:'creating new password element.',\
rev:'1',\
chain"
SecRule REQUEST_URI "@beginsWith /api/ciphers" \
"t:none,\
ctl:ruleRemoveTargetById=932220;ARGS:json.login.username,\
ctl:ruleRemoveTargetById=932236;ARGS:json.login.username,\
ctl:ruleRemoveTargetById=932220;ARGS:json.login.password,\
ctl:ruleRemoveTargetById=932236;ARGS:json.login.password,\
ctl:ruleRemoveTargetById=932220;ARGS:json.name,\
ctl:ruleRemoveTargetById=932236;ARGS:json.name,\
ctl:ruleRemoveTargetById=932220;ARGS:json.notes,\
ctl:ruleRemoveTargetById=932236;ARGS:json.notes,\
ctl:ruleRemoveById=921180"
This rule aims to allow the creation of a new password element while excluding specific ARGS related to the mentioned alert, thereby enhancing security configurations for Vaultwarden.
Summary
From @fzipi:
This should be valid ctl syntax:
ctl:ruleRemoveTargetById=123456;ARGS:/^mycookie_/
It doesn't work on ModSecurity: longstanding unfixed issues https://github.com/SpiderLabs/ModSecurity/issues/717 and https://github.com/SpiderLabs/ModSecurity/issues/911
Motivation
More args can be covered in the same rule rather than more declarations.