Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixel-perfect timing attacks with HTML5

contextis.co.uk

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Pixel-perfect timing attacks with HTML5

#11

Post by mistercow »

randallu wrote: post #10
mistercow wrote: post #6

Earlier quoted context omitted.

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 di…

>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.

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.

Re: Pixel-perfect timing attacks with HTML5

#12

Post by danielweber »

M4v3R wrote: post #2

These 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.

Google "Users want and demand a rich computing experience." Back in the 90's a Microsoft person made that claim on comp.risks. It kind of became a joke to call every new attack a "rich computing experience."

Re: Pixel-perfect timing attacks with HTML5

#13

Post by danielweber »

zubspace wrote: post #9

The 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 lo…

I know people who try to do interesting things for the users with iframes and are completely frustrated by things like that. File under "why we can't have nice things."

Re: Pixel-perfect timing attacks with HTML5

#14

Post by potench »

mistercow wrote: post #6
TylerE wrote: post #5

Earlier 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…

A few modern form features like placeholder text, required, and input type-casting for email, tel, number, and date reduce the need for JavaScript if you're willing to let the experience degrade pretty drastically on legacy browsers.

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".

Re: Pixel-perfect timing attacks with HTML5

#15

Post by sanderjd »

mistercow wrote: post #6
TylerE wrote: post #5

Earlier 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…

Developing the UI without using JS wouldn't be harder, it would make the UI less usable. As a user of online banking software, I don't think it worked at all as well "before the modern trend of trying to make everything act like a desktop app", I think it totally sucked. Maybe that's a worthwhile security trade-off, but let's at least talk about the real trade-off.

Re: Pixel-perfect timing attacks with HTML5

#16

Post by jimktrains2 »

TylerE wrote: post #5
mistercow wrote: post #4

It 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.

Ah! The opinion of someone who cares nothing about the functionality of the web as a whole.

JavaScript shouldn't be considered essential to use a website. If it is, the site has failed as it's job.

Re: Pixel-perfect timing attacks with HTML5

#17

Post by tptacek »

M4v3R wrote: post #2

These 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.

Don't think about security that way; that kind of logic is misleading. Security is measured in dollars, in the sense of cost imposed on attackers.

You're right that there's a constant tension between features and security.

Re: Pixel-perfect timing attacks with HTML5

#18

Post by aidos »

jffry wrote: post #3

This 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 man…

I love the way timing attacks seem so unlikely but actually easy ways to extract information.

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.

Re: Pixel-perfect timing attacks with HTML5

#19

Post by garethadams »

zubspace wrote: post #9

The 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 lo…

The default state for the web is usually "backward compatible".

Re: Pixel-perfect timing attacks with HTML5

#20

Post by hayksaakian »

mistercow wrote: post #6
TylerE wrote: post #5

Earlier 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…

Offhand I know that Chase.com uses JS in their online banking, almost for no reason too...
Post reply on HN