Pixel-perfect timing attacks with HTML5
contextis.co.uk
contextis.co.uk
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).
Everything about this attack is beautiful. A serious of seemingly unrelated issues that don't appear like a problem from the outside but when combined produce a solid attack that you could roll out today.
Well worth reading through the whole article.
is it possible to frame view-source?
<h1>IFrame, normal</h1>
<iframe src="http://www.example.com/"></iframe>
<h1>IFrame, view-source</h1>
<iframe src="view-source:http://www.example.com/"></iframe>
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?
if(top!=self) doNotFetchSensitiveInfoFromServer(true);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...).
[1] not explicitly mentioned there, but I think the solution described intends to plug that hole, too.
It really is a matter of features and how they're implemented.
Good luck picking a byte that can exploit a 7400.
One can always take the device and turn it on for oneself.
If one can't exploit the device, one can resort to rubber-hose cryptanalysis.
Security doesn't exist in isolation. AKA. there's always a way.
If you're talking about making a browser secure against internet-based attacks, there is not always a way. This type of security is merely extremely, overwhelmingly difficult.
You're right that there's a constant tension between features and security.
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.
Said no one who has ever had to develop a decent web ui.
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.
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!
Now that is a good point. In general, I don't know what to do about the weak link of email, which goes far beyond sniffing. I think it's hard for people to properly respect the gravity of their email's security when the vast majority of what comes through it is basically frivolous, or at least security-noncritical.
On a side note, I found the clip art at the top of the white papers distracting. Formatting, spacing, class names such as "nav", value="passwo".
JavaScript shouldn't be considered essential to use a website. If it is, the site has failed as it's job.
I was thinking, of course it doesn't help much in mitigating this attack, but they calculate average rendering times over several repeats of the same operation. When profiling performance timings, it's usually much more accurate to take the minimum execution time. The constant timing that you want to measure is part of the low-bound on the total time, any random OS process/timing glitch is going to add to that total time, but it will not somehow make the timespan you are interested in randomly run faster. There might be some exceptions to this, though (in which case I'd go for a truncated median or percentile range average or something).
Also had some ideas to improve performance on the pixel-stealing, as well as the OCR-style character reading. With the latter one could use Bayesian probabilities instead of a strict decision tree, that way it'll be more resilient to accidental timing errors so you don't need to repeat as often to ensure that every pixel is correct, just keep reading out high-entropy pixels and adjust the probabilities until there is sufficient "belief" in a particular outcome.
But as I understand from the concluding paragraphs of this paper, these vulnerabilities are already patched or very much on the way to being patched, otherwise I'd love to have a play with this :) :)