XSS and unintuitive content security policies

Hey all,

I recently put out a two part blog series about a Cross Site Scripting (XSS) situation I’ve encountered while doing Meteor security assessments.

The first post points out that while you might not be doing raw HTML injection within your application, a jQuery plugin, or other third-party code might be. This opens up the door to possible front-end vulnerabilities, like XSS.

The second post goes into more detail about XSS through a call to jQuery’s $.html(), such as:

let userInput = "<script>alert('hi!');</script>";
...
$(someElement).html(userInput);

Unintuitively, this type of XSS is not prevented by disallowing inline scripts (BrowserPolicy.content.disallowInlineScripts()) within your Meteor application. The injected Javascript is actually executed as part of an eval statement, and can only be prevented by your CSP if you’re disallowing unsafe eval (BrowserPolicy.content.disallowEval()).

We should all remember that while browser-policy is a useful tool, it’s not a panacea. We should still actively try to find and fix XSS vulnerabilities within our applications!

7 Likes