It's a bit of a misnomer as it's only for source-scripting in HTML/JS/CSS code. There's a lot of other things that ought to be done as part of a security check.
Basically XSS is showing looking for "naked parameters" -- where tools.getParamValue("foo") is used within stream processing.
The current guidance is to wrap the above in StringUtils.crossScriptingFilter(...) which escapes HTML characters.
Why not just redefine tools.getParamValue(), when invoked in a stream, to do this? And create a tools.getParamValueLiteral() function to work as traditionally? That would involve less code changes. Or visa-versa, define a tools.getParamValueSafe(). This would make the regexp checker easier.
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
I apologize for the lack of response. Hopefully, the following addresses the concerns that you have raised.
Rule Security Analyzer does static scan of underlying java and/or html of a variety of rules like activities like activities, sections, and text files. The scan uses regular expressions to find common high risk patterns that can cause issues like cross site scripting, SQL injection, and XML External Entity attacks.
While rule security analyzer is not run on rule check-in like guardrail warning checks, I believe that the rule security analyzer is run against our nightly core builds. It may be worth looking into where the existing rule security analyzer work could be used to used to enhance the existing set of guardrail warnings in order to identify potential issues sooner. The downsides would be that it would increase the time for rule check in, although I am unsure of the magnitude of the increase, and moving the rule security analyzer checks to the guardrail warning checks could also produce false positives since what is being checked for is a high risk pattern in the code, not a guaranteed issue. Also, the findings cite the issue in terms of the java code that the rule is converted into rather than in terms of the rule itself. This is not ideal for PRPC developers.
It would be easier if we could build the filter into the function instead of relying on developers to remember to use the filter and know which filter to use. Unfortunately, there is no one filter that is ideal for all cases and also putting the filter in the function may cause existing functionality to break (rule analyzer is useful for identifying areas where the existing functionality should be updated). Another advantage of having the filter functions separate from the input functions is the filters are defined only once and can be reused with the different methods of obtaining input.
And, as I noted in my first points, part of the reason for transitioning this to a regex-check framework, is so that we can easily extend that for checking *anything* in hardcoded HTML/JS code (deprecated JS, etc).