This is a personal blog. My other stuff: book | home page | Twitter | prepping | 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.

December 10, 2011

X-Frame-Options, or solving the wrong problem

On modern computers, JavaScript allows you to exploit the limits of human perception: you can open, reposition, and close browser windows, or load and navigate away from specific HTML documents, without giving the user any chance to register this event, let alone react consciously.

I have discussed some aspects of this problem in the past: my recent entry showcased an exploit that flips between two unrelated websites so quickly that you can't see it happening; and my earlier geolocation hack leveraged the delay between visual stimulus and premeditated response to attack browser security UIs.

A broader treatment of these problems - something that I consider to be one of the great unsolved problems in browser engineering - is given in "The Tangled Web". But today, I wanted to showcase another crude proof-of-concept illustrating why our response to clickjacking - and the treatment of it as a very narrow challenge specific to mouse clicks and <iframe> tags - is somewhat short-sighted. So, without further ado:

There are more complicated but comprehensive approaches that may make it possible for web applications to ensure that they are given a certain amount of non-disrupted, meaningful screen time; but they are unpopular with browser vendors, and unlikely to fly any time soon.

December 08, 2011

The old switcharoo

Another tiny proof-of-concept for the day: While the idea is fairly trivial, it seems pretty frightening to me - and neatly illustrates one of the points I'm making in The Tangled Web. I highly doubt that even the most proficient and attentive users would be able to spot this happening in the wild.

(If you don't get it, try again, and follow instructions on the screen.)

Interesting results can be also achieved in some browsers with history.back(), but I'll leave this as an exercise for readers. The same goes for the implications it has for clickjacking, drag-and-drop, and other attacks normally associated with frames.

PS. Another silly proof-of-concept as a bonus: click here.

December 02, 2011

CSS :visited may be a bit overrated

OK, second time is a charm. This script is probably of some peripheral interest: In the past two years or so, a majority of browser vendors decided to take a drastic step of severely crippling CSS :visited selectors in order to prevent websites from stealing your browsing history.

It is widely believed that techniques such as cache timing may theoretically offer comparable insights, but the attacks demonstrated so far seemed unconvincing. Among other faults, they relied on destructive, one-shot testing that altered the state of the examined cache; produced only probabilistic results; and were far too slow and noisy to be practically useful. Consequently, no serious attempts to address the underlying weakness have been made.

My proof of concept is fairly crude, and will fail for a minority of readers; but in my testing, it offers reliable, high-performance, non-destructive cache inspection that blurs the boundary between :visited and all the "less interesting" techniques.