XSS in URI / PATH_INFO going undetected

[dune73]

There is a false negative in the way we ignore onXXX events in the URI.

curl "http://localhost/index.html/x%22%3E%3CsvG%20onLoad=prompt(9)%3E"

If the same URI appears in the Referer, it triggers 941101, 941120 and 941160. Adding the URI to be covered by these rules, won't change a thing, so it's also an encoding problem.

[csanders-git]

So is the suggestion to add the URI to one of these rules

[dune73]

Not sure yet. But my customer just confirmed he wants me to come up with a solution here. So I'll dig into this and solve it.

[csanders-git]

I remember we used to have something for URL rewriting

[spartantri]

This is weird, the web server should reply with a 404 due to non existing resource as index.html is a directory and the x"> a file name.
I'm curious, what web server do they use? May they have a bad url rewriting pattern in place that allows this funny things to be accepted by turning that into something else? do you have a sample response?

[dune73]

;)

I rewrote the filename part of the URI to camouflage the real filename. Obviously I omitted the hostname, the slash and any real thought at a reasonable filename.

However, I do think enterprise CMS systems are more sophisticated than what you think. To the client, this index.html looks like a static page, but for the CMS it's dynamic ressource and /x%22... are all parameters / PATH_INFO for the request.

[spartantri]

There you go, I had exactly that in mind, this is not the web server it is the CMS doing bad rewrites to turn /x into ?x after modsec inspection without proper validation plus a nice non-escaped content reflection or store after that, don't you love developers, please tell me this is a php app to have a poker of nice little stuff in hand.

To me modsec REQUEST_FILENAME or REQUEST_URI vars could be added to the rules that check for ARGS and do not include on their inspection valid path and filename characters like / \ - _ . on PL1 to have the least of false positives but expect to have lot of issues and maybe a complete disaster on higher PL especially with those \W we have around so it may be good for PL1 and maybe PL2 but bad a complete no go for PL3 and PL4.

I will be happy to see more inspections on headers and request line that what he have now, we are ignoring lots of fun stuff.

[fgsch]

Another example (redacted): /something/other%3C%2Fscript%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E/

Is there any update on this @dune73 ?

[fgsch]

Can we start by adding the path to 941110? Or anyone thinks this will cause many FPs?

[dune73]

No progress. Sorry. I know it's on my todo list, but my life outside CRS is eating me alive these days. If anybody wants to take over, be my guest.

I think adding the path would make sense. @lifeforms: What do you think?

[theMiddleBlue]

agree with @fgsch. IMHO all XSS rules should look into REQUEST_FILENAME too

[fgsch]

I will submit a PR later today or tomorrow for 941110. I haven't had a chance to look into the other vectors in detail but I expect FPs at least until client9/libinjection#143 is merged, which seems to have gone awfully silent.

[github-actions]

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days