Pixel-perfect timing attacks with HTML5
contextis.co.uk
Pixel-perfect timing attacks with HTML5
1–10 of 47 posts
Re: Pixel-perfect timing attacks with HTML5
#2These attacks are getting more and more creative. I begin to think that there is no such thing as perfect security in a world that constantly demands new features.
Re: Pixel-perfect timing attacks with HTML5
#3This is a fascinating attack. Definitely read the bits on the SVG filter timing attacks. They construct something that allows distinguishing black pixels from white pixels, apply a threshold filter to an iframe, and then read out pixels from the contents of that iframe.
Then they turn this around, set an iframe's src to "view-source:https://example.com/", and read out information from there (in a more efficient manner).
Re: Pixel-perfect timing attacks with HTML5
#4It seems to me like a web server ought to be able to send some signal to browsers on either a single page or subdomain basis, which disables JS for those pages. If another page includes such a JS-disabled page in an iframe, then at the very least, all scripts on the parent page should be immediately terminated, and ideally loading of the iframe should fail if any scripts have executed (obviously an exception should be made for, e.g. Chrome extensions).
This should completely nullify a vast number of potential attacks for sites that are particularly sensitive. There's no reason, for example, that the logged-in portion of a banking site should need to use JS. That seems like a reasonable sacrifice for adding significant security to critical websites.
Re: Pixel-perfect timing attacks with HTML5
#5It seems to me like a web server ought to be able to send some signal to browsers on either a single page or subdomain basis, which disables JS for those pages. If another page includes such a JS-disabled page in an iframe, then at the very least, all scripts on the parent page should be immediately terminated, and ideally loading of the iframe should fail if any scripts have executed (obviously an exception should b…
> There's no reason, for example, that the logged-in portion of a banking site should need to use JS.
Said no one who has ever had to develop a decent web ui.
Re: Pixel-perfect timing attacks with HTML5
#6It seems to me like a web server ought to be able to send some signal to browsers on either a single page or subdomain basis, which disables JS for those pages. If another page includes such a JS-disabled page in an iframe, then at the very least, all scripts on the parent page should be immediately terminated, and ideally loading of the iframe should fail if any scripts have executed (obviously an exception should b…
> There's no reason, for example, that the logged-in portion of a banking site should need to use JS. Said no one who has ever had to develop a decent web ui.
That's what I do professionally, and I can say with confidence that a banking website does not need to use JS. There is no functionality there that can't be done the old-fashioned way.
Online banking does not need to be a rich HTML5 experience, and online banking worked just as well as it does today before the modern trend of trying to make everything act like a desktop app.
Would developing the UI without using JS be harder? Yes, marginally. Is it worth opening up security vulnerabilities to make development slightly easier? No. Just in terms of how much each of those costs the bank, no. From the users' perspective, no.
Re: Pixel-perfect timing attacks with HTML5
#7These same guys had previously used WebGL to suck out text in the same way; unfortunately the demo is no longer at the same URL, but it is what's responsible for the fairly weird implementation of CSS Shaders: http://www.schemehostport.com/2011/12/timing-attacks-on-css-...
It's amazing that the same thing can be observed with the standard SVG software filters, though. I'd imagine that using X-Frame-Deny as they suggest is a much better solution than killing all JS (because you just know some incompetent ad network will manage to flip the switch and break millions of pages with that ability...).
Re: Pixel-perfect timing attacks with HTML5
#8These attacks are getting more and more creative. I begin to think that there is no such thing as perfect security in a world that constantly demands new features.
There is no such thing as perfect security.
Re: Pixel-perfect timing attacks with HTML5
#9The paper describes how to prevent the sniffing attack:
Website owners can protect themselves from the pixel reading attacks described in this paper by disallowing framing of their sites. This can be done by setting the following HTTP header:
X-Frame-Options: Deny
This header is primarily intended to prevent clickjacking attacks, but it is effective at mitigating any attack technique that involves a malicious site loading a victim site in an iframe. Any website that allows users to log in, or handles sensitive data should have this header set.
I wonder, why is this option an opt-out and not an opt-in? Shouldn't this be the default?
Re: Pixel-perfect timing attacks with HTML5
#10Earlier quoted context omitted.
> There's no reason, for example, that the logged-in portion of a banking site should need to use JS. Said no one who has ever had to develop a decent web ui.
That's what I do professionally, and I can say with confidence that a banking website does not need to use JS. There is no functionality there that can't be done the old-fashioned way. Online banking does not need to be a rich HTML5 experience, and online banking worked just as well as it does today before the modern trend of trying to make everything act like a desktop app. Would developing the UI without using JS b…
GMail, etc, is just as important from a security perspective as your banking site since it could be used to perform a password reset. It could conceivably be iframe'd and have its contents sucked out.
It's unlikely that every link in the chain will stop using JS, so we must develop more creative methods.
There's also a history attack in here based on observing a repaint due to a link changing color. So even if one did turn off JS due to some signal, oppressive regime X could still sniff if their subjects had visited website Y and do bad things to them. At this point tracking visited links seems like it's more trouble than it's worth!