Malicious POST request logged as GET request in audit logs #3302
Labels
3.x
Related to ModSecurity version 3.x
Comments
Dr-Lazarus-V2
changed the title
|
I have conducted a further investigation and can note that even a request which triggerers a CRS rule has the same issue. In the audit logs this is logged as a GET and not a POST. |
|
I believe this issue relates to the REQUEST_METHOD being reset on redirection: Issue My Nginx configuration involves a redirect: There is a workaround metioned by @hator |
|
This issue seems to be a duplicate of another issue opened earlier in the Modsecurity-Nginx connector Issue Hence I am closing it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I have created a custom rule to detect the word
confidentialin theREQUEST_BODY. If the word is detected, the action to undertake isdeny. However when I make thisPOSTrequest the request is logged as aGETin the audit logs.Here is the custom rule:
Logs and dumps
Audit Logs
{ "transaction": { "client_ip": "10.103.253.240", "time_stamp": "Thu Nov 14 05:08:27 2024", "server_id": "327c12d21520fbed95c8764ad076e59b7ea5d783", "client_port": 51501, "host_ip": "192.168.32.3", "host_port": 8080, "unique_id": "8f198db9483934603d69ce8654326042", "request": { "method": "GET", "http_version": 1.1, "uri": "/check", "headers": { "Content-Type": "application/json", "User-Agent": "PostmanRuntime/7.42.0", "Postman-Token": "6936971e-b447-4419-8f95-262f0a590386", "Accept": "*/*", "Host": "weborion.licensing.portal", "Accept-Encoding": "gzip, deflate, br", "Connection": "keep-alive", "Content-Length": "21" } }, "response": { "http_code": 403, "headers": { "Server": "nginx/1.27.2", "Date": "Thu, 14 Nov 2024 05:08:27 GMT", "Content-Type": "text/html", "Connection": "keep-alive", "ETag": "\"66dfdff2-93d6\"" } }, "producer": { "modsecurity": "ModSecurity v3.0.13 (Linux)", "connector": "ModSecurity-nginx v1.0.3", "secrules_engine": "Enabled", "components": [ "OWASP_CRS/4.8.0\"" ] }, "messages": [ { "message": "GET or HEAD Request with Body Content", "details": { "match": "Matched \"Operator `Rx' with parameter `^0?$' against variable `REQUEST_HEADERS:Content-Length' (Value: `21' )", "reference": "o0,3v0,3v255,2", "ruleId": "920170", "file": "/etc/modsecurity.d/owasp-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf", "lineNumber": "171", "data": "21", "severity": "2", "ver": "OWASP_CRS/4.8.0", "rev": "", "tags": [ "application-multi", "language-multi", "platform-multi", "attack-protocol", "paranoia-level/1", "OWASP_CRS", "capec/1000/210/272" ], "maturity": "0", "accuracy": "0" } }, { "message": "UNAUTHORIZED DATA ACCESS", "details": { "match": "Matched \"Operator `Rx' with parameter `(?i)(\\b|\\W*)confidential' against variable `REQUEST_BODY' (Value: `{\"confidential\":true}' )", "reference": "o0,14o0,2v258,21", "ruleId": "1", "file": "/var/opt/modsecurity.d/custom-ruleset/TestRukeset/TestRukeset-RULES.conf", "lineNumber": "1", "data": "", "severity": "0", "ver": "", "rev": "", "tags": [], "maturity": "0", "accuracy": "0" } }, { "message": "Inbound Score: 5 Outbound Score: 0", "details": { "match": "", "reference": "", "ruleId": "980145", "file": "/var/opt/modsecurity.d/owasp-crs/weborion.licensing.portal.crs_setup.conf", "lineNumber": "40", "data": "", "severity": "0", "ver": "", "rev": "", "tags": [], "maturity": "0", "accuracy": "0" } } ] } }Debug Logs (Level 9)
Modsecurity-Debug-Logs-Level-9.txt
A more closer view:
In the logs above you can see that for the same
unique_id8f198db9483934603d69ce8654326042, theREQUEST_METHODvariable value changes fromPOSTtoGETError Logs:
In the error log the same request gets logged twice, it gets logged as POST request.
To Reproduce
POSTendpoint in the server/webApp protected by the WAF.Curl Command
curl --location 'http://<domain>/check' \ --header 'Content-Type: application/json' \ --data '{"confidential":true}'Expected behavior
The audit logs should log the request as
POSTand notGET.Server (please complete the following information):
Rule Set (please complete the following information):
Additional context
I can see that the transaction starts again when the custom rule is triggered.
I am not sure if this is the expected behaviour from the backed. After this process it seems that the request goes through all the 4 phases again, however this time the
REQUEST_METHODbecomesGETThe text was updated successfully, but these errors were encountered: