Password scrubbing

[a-zb]

Describe the bug

Sanitization of passwords does not seem to work. Password is recorded
in audit log when caught by owasp CRS 3.2 libinjection rule.

Libinjection CRS rule has an output format that outputs the VAR name and values, and mod_sec module does not sanitize it, please see this log output. The rule can be triggered by putting in a character sequence of !@# within the password. How do we prevent showing these values within the H section:

configuration
We have following config as an example

SecAction "nolog,auditlog,phase:2,id:131,sanitiseArg:password"
SecRule ARGS "password" "phase:1,log,deny,id:119,t:removeNulls,t:lowercase,multiMatch"
SecRule REQUEST_URI "@beginswith /apply/" "phase:5,nolog,auditlog,id:10004,ctl:ruleRemoveTargetById=942100;ARGS:password"

Logs and dumps

The audit log masks some of the arguments:
--40105004-C--
login=USER&password=****************&submitButton=Log+In&csrf=0762a687ea5b99774b6dd3194576f184
--40105004-F--
HTTP/1.1 303 See Other
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

--40105004-H--
Message: Unconditional match in SecAction. [file "/etc/httpd/conf.d/mod_security.conf"] [line "5"] [id "131"]
Message: detected SQLi using libinjection with fingerprint 'novc' [file "/etc/httpd/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "67"] [id "942100"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: novc found within ARGS:password: Pass555!@#"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
Message: Warning. Operator GE matched 5 at TX:anomaly_score. [file "/etc/httpd/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "91"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"]
Message: String match "/apply/" at REQUEST_URI. [file "/etc/httpd/conf.d/mod_security.conf"] [line "12"] [id "10004"]
Message: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/etc/httpd/owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "86"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [tag "event-correlation"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 192.168.0.16] ModSecurity: Warning. Operator GE matched 5 at TX:anomaly_score. [file "/etc/httpd/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "91"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "host"] [uri "/apply/toolset/en_CA/user/login"] [unique_id "Xqchg5Xdaqirl7Fz7LwtvwAAAME"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 192.168.0.16] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/etc/httpd/owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "86"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [tag "event-correlation"] [hostname "host"] [uri "/user/login"] [unique_id "Xqchg5Xdaqirl7Fz7LwtvwAAAME"]
Apache-Handler: proxy-server
Stopwatch: 1588011395366437 46766 (- - -)
Stopwatch2: 1588011395366437 46766; combined=5048, p1=391, p2=4297, p3=37, p4=153, p5=169, sr=16, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/); OWASP_CRS/3.2.0.
Server: Apache/2.4.6 () OpenSSL/1.0.2k-fips
Sanitised-Args: "password".
Engine-Mode: "DETECTION_ONLY"

[martinhsv]

Hi @arekzb ,

It looks like that's a longstanding limitation related to section H output. I.e. if the a rule itself is directing a matched value to be written to the log using variables (e.g. MATCHED_VAR) then that will not get sanitized.

For a particular false positive like the one you have here, you have a few options that you could consider:

1. you could decide not to evaluate rule 942100 when the arg is 'password'. You could either exclude that arg name directly as part of that rule or you could use a separate rule to remove the target via ctl:ruleRemoveTargetById. This is often appropriate since a well-understood FP should neither block traffic nor (ideally) pollute the logs
2. You could consider removing part H logging for some detections. For example: a rule that tests for REQUEST_FILENAME including 'login' (or whatever is appropriate in your case) and then as one of its actions does ctl:auditLogParts=-H
3. Similarly to the previous item, you could exclude part H if the name 'password' is included in any of the request arguments.

There are other possibilities as well but those art the ones I can think of that seem most likely to be the useful to you.