Script restrictions for mitigating XSS vulnerabilities

It looks like Robert Sayre is implementing Gerv's Content Restrictions proposal. This will give web sites a way to specify where in the page scripts are allowed to appear. The idea is that if a site using Content Restrictions has an XSS hole (e.g. due to incorrectly escaped text or incorrectly sanitized user HTML), it won't be exploitable in browsers that support Content Restrictions.

I'd rather see anti-XSS effort focused on improving server-side libraries. For example, if web applications were written in terms of "constructing an HTML DOM tree" or "pushing and popping HTML elements", much less code would have to be audited for "remembering to escape output" (I hate that phrase). But it's hard to argue against something that seems like it will help mitigate holes in existing web applications.

Readers who found this interesting might also enjoy Mozilla's metabug for anti-XSS proposals (dependency tree).

4 Responses to “Script restrictions for mitigating XSS vulnerabilities”

  1. Justin Says:

    Personally I think Gerv has the right idea. I did a survey of XSS protections earlier this year and his proposal was the only one I found that addressed the issue as a combination of client and server responsibilities. I’ve also posted some thoughts on a broader approach that I’d been mulling over . Basically, I’m of the opinion that same-origin could use a bit of an upgrade.

    Of course, I completely agree with the benefits of pushing user-malleable data out-of-band. Plus, it’s already a common practice in SQL via prepared statements and stored procedures. However, a few years ago I played around with building “safe” HTML entirely through server-side DOM manipulation. The result was clunky and had serious performance issues. Line-by-line HTML output ended up being a lot less resource-intensive than maintaining and manipulating a complete DOM tree in memory.

    I’m sure that my HTML generation issues could be mostly addressed by developing a good toolkit, but that’s still only a partial solution. It doesn’t matter if it’s a stack frame or HTML, it’s best to plan for potential overlap of user-data and application metadata. So, I’m all for a more robust form of HTML generation, but I’d also like to see some defense-in-depth against the range of origin-related vulnerabilities (like CSRF).

    Regardless, it’s nice to see forward progress in this area. I’m not working on web app security these days, but I’m glad to see things moving forward.

  2. Robert Sayre Says:

    I’m implementing it just to see what would happen. I’m not sure the proposal is a good idea either.

  3. Rob Sayre’s Mozilla Blog » Blog Archive » Interoperability and XSS Mitigation Says:

    [...] lot people say this. Jesse is the latest. These days, there are some good libraries. There’s even one for PHP. But input [...]

  4. Dominic Mitchell Says:

    I always like the phrase “generating HTML”. If you’re just chucking strings together, you’re not generating HTML, you’re generating security holes…