Hacker News Reader

Hacker News

Comment by jacobparker | Hacker News Reader

Full thread

jacobparker

Some modern tools to mitigate XSS/make XSS virtually impossible:

- Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/Security/CSP/In...

- The sandbox attribute on iframes: https://developer.mozilla.org/en/docs/Web/HTML/Element/ifram...

XSS is one of the hardest things to keep under control at scale.

View on HN

I've gotten into the habit of starting off every new project of mine with the header "Content-Security-Policy: script-src 'self'" on all pages, and whitelisting domains and 'unsafe-eval' as I need them. ('unsafe-eval' isn't so bad. 'unsafe-inline' is the really unsafe one that you want to avoid because it undoes the XSS protection. Eval has legitimate uses and eval-based vulnerabilities are not anywhere near as easy to accidentally create and never notice as a regular XSS vulnerability. I'd bet that everyone who has really written Javascript+HTML without CSP has created a regular XSS vulnerability at some point.)

There's no excuse to not start new projects off with a CSP rule like that. Doing it from the start means you won't ever have to comb through your codebase later to remove all bits of inline javascript that you depend on to get the benefits.

A much better way to mitigate XSS/HTML injections is not using string functions to generate HTML.

CSP prevents an attacker from executing scripts, but the attacker can still corrupt your HTML.

Some examples detailing the dangers of HTML corruption: http://lcamtuf.coredump.cx/postxss/.

Yep. XSS isn’t at all hard to prevent if you’re using tools that are safe by default. Unfortunately, popular ones like jQuery aren’t. (This, more than any other, is a reason to prefer the DOM API.)

I'm not sure the DOM API is safer. innerHtml vs html()

If you're assigning untrusted text to a property called `innerHTML`, you shouldn't be surprised to learn that you're vulnerable to XSS.

APIs like jQuery are worse because you end up treating strings as HTML without even realizing it. Example from the article:

  $("#tail-here").prepend(newlines);

There's no hint on that line that the `newlines` variable is interpreted as HTML instead of text.

Pfft. Straight from the documentation of the method:

  content
  Type: >>htmlString<< or Element or Array or jQuery

You could argue that the API is bad for allowing HTML strings as arguments, but it's not really surprising that a function does what it is documented to do. Especially since these are DOM manipulation, not string manipulation functions.

Everything in jQuery is DOM manipulation. (Well, except for the little extra parts that aren't like $.ajax.) Tons of websites' code is primarily just jQuery calls because DOM manipulation is what makes things happen on the web.

The only native DOM API calls that can get you an XSS vulnerability are sets to `innerHTML`, `outerHTML`, and maybe some few others. Most of the methods for getting things done don't have any possibility of introducing an XSS issue. With jQuery, many methods including every method capable of inserting elements is also capable of introducing an XSS issue depending on the types passed to them. So you when you're reviewing for XSS issues, you have many more places to check, and analyzing the calls to jQuery methods to see if they have the potential for XSS is much more difficult because you have to trace the path backwards from every single call to see what types are set into the variables passed to the methods.

> You could argue that the API is bad for allowing HTML strings as arguments

That is exactly what I’m arguing, yes.

> but it's not really surprising that a function does what it is documented to do

It doesn’t have to be surprising or undocumented to be stupid.

  > You could argue that the API is bad for allowing HTML strings as arguments
  That is exactly what I’m arguing, yes.

And how native DOM helps there?

There are relatively few DOM APIs which take a trusted string. innerHTML and outerHTML are two and clearly state that they take HTML so it's no surprise for the stuff you give them to be interpreted thus. But if you use e.g. textContent or createTextNode to insert text into your document, they will correctly sanitise it.

jQuery has text()[0], but because most of its API takes strings to start with, it's very convenient to do the wrong thing and shove untrusted strings into unsafe methods.

[0] http://api.jquery.com/text/#text2

yes, API takes strings, but it calls native DOM at the end anyway, so I still don't get what's your point.

> yes, API takes strings, but it calls native DOM at the end anyway

jQuery calls unsafe API which should only be handled trusted strings but makes it easy and convenient to give them untrusted string and thus introduce exploit vectors.

Furthermore it's also significantly more difficult to audit the code, using the regular DOM there are only a pair of attributes to check, whereas pretty much any jQuery method call is a potential security hole.

tldr: jQuery makes doing things wrong very easy, much easier than doing things right.

You can use CSP to prevent content exfiltration as well, not just script execution. There's a number of directives suited for that: img-src, form-action, child-src, etc. Full list on MDN: https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CS...

CSP rules are a good defense-in-depth measure to most likely limit the reach of vulnerabilities. They're not a cure-all that makes it so you don't have to understand HTML/text encoding.

It's like what ASLR and stack canaries do for buffer overflow vulnerabilities in C/C++. You still should try to avoid writing buffer overflow bugs, but if/when they do happen, the protections mean that the issue will probably just be a denial-of-service issue rather than an issue that lets an attacker execute code on your systems.

jacobparker: Indeed. I added related headers to my web server conf after the fact (https://github.com/WillieStevenson/conf-files/blob/master/ng...). I should of have mentioned it in my post.

One of the projects I'm working on aims to make it easier to integrate CSP headers into web applicatons.

https://github.com/paragonie/csp-builder

I'm working this week to integrate it into another project we're developing. (It's MIT licensed, so have fun with it.)

Hi CiPHPerCoder. Can I PM you?

On Twitter? Yes, my DMs are open. Feel free to email me too:

    security@ my company's domain name

I'm pretty sure HN doesn't have PMs.

Reply on news.ycombinator.com