JS: Handle jQuery $() sink in a separate data-flow configuration #4506
Conversation
esbena
left a comment
esbena
left a comment
There was a problem hiding this comment.
Very nice.
I am glad that this multi-Configuration pattern still scales.
| * An argument to the jQuery `$` function, which is interpreted as either a selector | ||
| * or as an HTML string depending on its first character. | ||
| */ | ||
| class JQuerySelectorSink extends Sink { |
There was a problem hiding this comment.
Two things here:
- naming: this is a sink because it could interpret the argument as HTML rather than a benign selector.
- reuse: could we unify this with
AmbiguousHtmlOrSelectorArgument?
There was a problem hiding this comment.
Renamed to JQueryHtmlOrSelector... and shared some logic with AmbiguousHtmlOrSelectorArgument.
| /** | ||
| * DEPRECATED. Use `HtmlInjectionConfiguration` or `JQuerySelectorInjectionConfiguration`. | ||
| */ | ||
| deprecated class Configuration = HtmlInjectionConfiguration; |
There was a problem hiding this comment.
Have you considered mentioning this deprecation explicitly in the change notes? I would expect this particular Configuration instance to be the one that is most commonly imported in external queries.
| from DataFlow::Configuration cfg, DataFlow::PathNode source, DataFlow::PathNode sink | ||
| where | ||
| ( | ||
| cfg instanceof HtmlInjectionConfiguration or |
There was a problem hiding this comment.
In these BDD-times, could you perhaps also check if the compiler stays happy if you include a few more (dummy) configurations in this disjunct?
There was a problem hiding this comment.
Adding two more configs seems to trigger the memory limit 😬
asgerf
force-pushed
the
js/separate-jquery-config
branch
from
fadc465 to
c91cdb5
Compare
esbena
left a comment
esbena
left a comment
There was a problem hiding this comment.
Thanks. I think we should merge regardless of the newly discovered compilation limit, that is not the fault of this PR after all.
I have one more optional comment on the change note.
| ## Changes to libraries | ||
| * The predicate `TypeAnnotation.hasQualifiedName` now works in more cases when the imported library was not present during extraction. | ||
| * The class `DomBasedXss::Configuration` has been deprecated, as it has been split into `DomBasedXss::HtmlInjectionConfiguration` and `DomBasedXss::JQueryHtmlOrSelectorInjectionConfiguration`. Unless specifically working with jQuery sinks, uses of that | ||
| class should be replaced with `HtmlInjectionConfiguration`. |
There was a problem hiding this comment.
Could we also point the reader towards our Xss.ql for how to use both configurations at once? That is after all how you would work around this deprecation with a customized XSS query.
3 participants
The jQuery
$()function interprets its input as HTML only if it starts with<.To avoid FPs from an expression like
$(location.hash)which always starts with#, the XSS query treated the.hashproperty specially, but in a way that could cause FNs for other kinds of sinks, likeinnerHTMLassignments, where it doesn't matter what the string starts with.This PR moves handling of the jQuery sink into a separate data-flow configuration. Most importantly, this allows us to tweak the jQuery sink handling without interfering with other sinks. We now handle the jQuery sink by requiring that any value derived from
.hashmust have undergone some transformation before reaching$().Evaluation (internal link) was quiet.