CODEWITHSUNDEEP
javascriptjqueryhtmlsecurity
rjdkolb
rjdkolb

Reputation: 11858

Selector interpreted as HTML on my website. Can an attacker easily exploit this?

I have a website that is only accessible via https.

It does not load any content from other sources. So all content is on the local webserver.

Using the Retire.js Chrome plugin I get a warning that the jquery 1.8.3 I included is vulnerable to 'Selector interpreted as HTML' (jQuery bug 11290)

I am trying to motivate for a quick upgrade, but I need something more concrete information to motivate the upgrade to the powers that be. My question are :

Upvotes: 1

Views: 2195

Answers (2)

Erlend
Erlend

Reputation: 4416

As the author of Retire.js let me shed some light on this. There are two weaknesses in older versions of jQuery, but those are not vulnerabilities by themselves. It depends on how jQuery is used. Two examples abusing the bugs are shown here: research.insecurelabs.org/jquery/test/

The two examples are:

$("#<img src=x onerror=...>")

and

$("element[attribute='<img src=x onerror=...>'")

Typically this becomes a problem if you do something like:

$(location.hash)

This was a fairly common pattern for many web sites, when single page web sites started to occur.

So this becomes a problem if and only if you put untrusted user data inside the jQuery selector function.

And yes the end result is XSS, if the site is in fact vulnerable. https will not protect you against these kinds of flaws.

Upvotes: 1

T.J. Crowder
T.J. Crowder

Reputation: 1074495

What the bug is telling you is that jQuery may mis-identify a selector containing a < as being an HTML fragment instead, and try to parse and create the relevant elements.

So the vulnerability, such as it is, is that a cleverly-crafted selector, if then passed into jQuery, could define a script tag that then executes arbitrary script code in the context of the page, potentially taking private information from the page and sending it to someone with malicious (or merely prurient) intent.

This is largely only useful if User A can write a selector that will later be given to jQuery in User B's session, letting User A steal information from User B's page. (It really doesn't matter if a user can "tricky" jQuery this way on their own page; they can do far worse things from the console, or with "save as".)

So: If nothing in your code lets users provide selectors that will be saved and then retrieved by other users and passed to jQuery, I wouldn't be all that worried. If it does (with or without the fix to the bug), I'd examine those selector strings really carefully. I say "with or without the bug" because if you didn't filter what the users typed at all, they could still just provide an HTML fragment where the first non-whitespace character is <, which would still cause jQuery to parse it as an HTML fragment.

Upvotes: 5

Related Questions