This is a personal blog. My other stuff: book | home page | Twitter | CNC robotics | electronics

December 19, 2011

Notes about the post-XSS world

Content Security Policy is gaining steam, and we've seen a flurry of other complementary approaches that share a common goal: to minimize the impact of markup injection vulnerabilities by preventing the attacker from executing unauthorized JavaScript. We are so accustomed to thinking about markup injection in terms of cross-site scripting that we don't question this approach - but perhaps we should?

This collection of notes is a very crude thought experiment in imagining the attack opportunities in a post-XSS world. The startling realization I had by the end of that half-baked effort is that the landscape would not change that much: The hypothetical universal deployment of CSP places some additional constraints on what you can do, but the differences are not as substantial as you may suspect. In that sense, the frameworks are conceptually similar to DEP, stack canaries, or ASLR: They make your life harder, but reliably prevent exploitation far less frequently than we would have thought.

Credit where credit is due: The idea for writing down some of the possible attack scenarios comes from Mario Heiderich and Elie Bursztein, who are aiming to write a more coherent and nuanced academic paper on this topic, complete with vectors of their design, and some very interesting 0-day bugs; I hope to be able to contribute to that work. In the meantime, though, it seems that everybody else is thinking out loud about the same problems - including Devdatta Akhawe and Collin Jackson - so I thought that sharing the current notes may be useful, even if the observations are not particularly groundbreaking.

6 comments:

  1. This makes me wonder if instead of the script-nonce approach (where we use a nonce to mark off a trusted script), we should just have the "use this nonce to mark off untrusted markup: anything inside of this box should not break out" (via formaction or consumption of tokens or allowing a script tag inside etc)

    ReplyDelete
  2. The guard token approach is commonly brought up, and I think it would be beneficial to web applications; I mention it in "The Tangled Web".

    That said, this trick was repeatedly rejected by browser vendors, essentially on standards purity grounds: guard tokens have no valid serialization in XHTML.

    I think it's a very weak rebuttal (i.e., purity of essence should not be a top-priority goal, especially if you're already in a horribly messy situation)... but if you're not actually writing the code, arguments won't win you much :-)

    ReplyDelete
  3. Meredith Patterson goes after this problem by analysing hackability as a computability problem. She's very convincing.

    See http://www.i-programmer.info/news/149-security/3541-the-computer-science-of-insecurity.html

    ReplyDelete
  4. Thought you'd be interested in this: http://www.scmagazine.com.au/News/284877,analysis-html5-security-holes-detailed.aspx?

    ReplyDelete
  5. What is the problem with using the iframe sandbox instead of guard token?

    < iframe seamless sandbox srcdoc="URI encoded content" >< / iframe >

    The fact that there has to be an escape (as opposed to the guard token which might be transparent) is a small price to pay for the fact that it is already in the standard.

    Also, what would be the policy inside the sandbox? You don't talk much about the details in TTW IIRC. Should you turn on CSP inside content protected by guard token?

    What do you do if attacker provides the URI (for say an image) but you provide rest of the code?

    Or is it only the HTML context sanitization that you are interested in? Because clearly that's the hardest one, but it is useful to think about other issues.

    ReplyDelete
  6. Sandboxed frames have several problems that I think make them less suited for all-around XSS prevention, including their performance impact (they aren't very useful for containing hundreds or thousands of short snippets of attacker-controlled data); limited content policing capabilities as designed; limited DOM access to their contents for the "owner" page; and clunky syntax of srcdoc that requires more ambitious framework-level support, and is harder to debug.

    [ My other fear with srcdoc is that if you don't escape the value correctly, it won't immediately fail, but you will have XSS. And given that people not being able to escape consistently is the root of XSS to begin with... ]

    In any case, they are an OK alternative to some of the most rudimentary cases of server-side HTML sanitization, for example for the purpose of displaying received HTML e-mails - but even there, markup sanitization needs vary so greatly that it won't be a drop-in replacement, and in many cases, may not be enough at all.

    They are now standardized, so yeah, that's a good argument to use them where feasible, versus debating some pipe-dream of guard tokens ;-)

    As for the policy inside, I remember seeing several proposals, but really, it almost seems pointless to rehash it, given that this is almost certainly not happening unless somebody implements and ships it, and then perhaps also convinces a standards body that we can ignore XHTML for a moment (yeah, right).

    /mz

    ReplyDelete