941150 (XSS Filter) FP

[jschleus]

Similar to issue #546:

The rule 941150 gives on a server offering FOSS software and software package member browsing
FPs ("XSS Filter - Category 5: Disallowed HTML Attributes") if users come for e.g. via a Google search and request URLs with the string "src" in the path (like for e.g. in "/linux/openscad/src/openscad.cc").

In that case the Referer header contains (at least by the Google parameters like "cd=", " ved=" or "usg=" ) mostly a "=" so that the rule matches.

The behaviour seems reproducable for e.g. by

curl -H "Referer: http://foo.bar/src&ved=" ...

Ok, as a workaround probably I can set "tx.allow_html=1" or remove "REQUEST_HEADERS:Referer" from the SecRule variables but ....

By the way I found no according "Matched Data:" entries in modsec_audit.log although the regex is "captured" and the rule 941150 contains

logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}'

is that expected?

[lifeforms]

Thanks for submitting this.

This is an existing XSS rule which is pretty sensitive. I added Referer to the check pretty late in the cycle, since there's lots of XSS vulnerabilities in log analyzers/viewers. This regexp as it stands is much too broad in the characters after the keyword. I think it's best to remove Referer from this rule. Maybe we can bring a more strict version back in the future.

While we're at it, the chain SecRule TX:ALLOW_HTML "@eq 0" should be removed too since that feature is gone - and the comment should be fixed to reflect this.

[dune73]

While I agree with @lifeforms, I am not able to reproduce the alert. Could you please give a full example, @jschleus?

[jschleus]

I just installed for a clean test the current CRS v3.0.0 RC2 on a local test server and I could trigger succesfully the rule 941150 with the further reduced test string

 curl -H "Referer: src=" http://localhost/

and also with (the two other strings checked in the rule pattern)

 curl -H "Referer: style=" http://localhost/
 curl -H "Referer: href=" http://localhost/

(ok, localhost is replaced by a artificial host name since a virtual host is in use).

What is confusing and what I forgot to mention is that in modsec_audit.log only the rule IDs 949110 and 980130 appear. I have found the matching rule only by removing successively all the rules in REQUEST-941-APPLICATION-ATTACK-XSS.conf. As a check I have again removed "REQUEST_HEADERS:Referer" from the SecRule variables in 941150 and the above accesses were no longer blocked (similar as if you remove one character in the above Referer values) .

Naturally your tx.critical_anomaly_score must be set @ge tx.inbound_anomaly_score_threshold (but that is the default).

If the above informations are still not sufficient I will try to give a full modsec_audit.log entry block (at the moment I failed due newbie problems with the GitHub formatting).

[csanders-git]

@lifeforms want me to make a PR with the refer removed?

[jschleus]

I personally would appreciate it.

Just for completeness: On the server I manage there occurred also some FPs caused by the related rule 941130 but in contrast to the above they are very rare and probably very specific. They are also triggered by referers, for e.g. if they contain strings (file names) like

Feature-66269-FluidRemoveViewHelperXmlnsAttributesAndSpecifiedHtmlTag.rst  ("xmlns")
struct__xmlNs.html  ("xmlns") 
objdump.patterns  ("pattern")
AuthenticationViaFormAction.java-diff.html  ("formaction")

[csanders-git]

Closed in favor of PR #585