Java: Improve performance of XSS regex.

[aschackmull]

@jbj highlighted a case where the regex matching in isXssVulnerableContentType was a noticeable bottleneck - it's slow and it's evaluated multiple times.

Timing it locally, I measured one of the cases to 2.5s.
Merging the 4 regexes to 1 brought that down to about 670ms.
And testing the resulting regex on a single-column projection brought that further down to about 90ms.

This makes sense, since checking a single regex is much faster than checking 4. And projecting CompileTimeConstantExpr.getStringValue() to the string column easily reduces the number of regex operations by an order of magnitude when many string literals have the same value.

Copilot wasn't able to review any files in this pull request.

Files not reviewed (3)

• java/ql/lib/semmle/code/java/frameworks/JaxWS.qll: Language not supported
• java/ql/lib/semmle/code/java/frameworks/spring/SpringHttp.qll: Language not supported
• java/ql/lib/semmle/code/java/security/XSS.qll: Language not supported

Tip: If you use Visual Studio Code, you can request a review from Copilot before you push from the "Source Control" tab. Learn more

[aschackmull]

I could btw. cut the 670ms in half by switching the column order, since that makes the string pool cache more efficient, but it'll still evaluate the regex for each row, so it's not really competitive with the regex-on-projection solution. I also tried instrumenting the evaluator to exploit the sorted strings case (i.e. the switched column order) by adding a very lightweight single-tuple cache to skip regex evals on identical tuples, but this took about 280ms, so it still didn't compete with the regex-on-projection even though it ought to have computed the same number of regex and string pool operations.

[aschackmull]

Wow, this actually shows as a more significant improvement on dca than I expected 🎉