21–30 of 47 posts
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.
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.
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…
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.
These 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 sugge…
[1] not explicitly mentioned there, but I think the solution described intends to plug that hole, too.
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…
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.
There is no such thing as perfect security.
It really is a matter of features and how they're implemented.
Good luck picking a byte that can exploit a 7400.
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…
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.
Earlier quoted context omitted.
There is no such thing as perfect security.
You can always turn the device off. 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.