3 ms·

Webdevs are aware of flaws in their browser so that they have to hack up a bunch of javascript in order to safely login instead of cooperating with the browser

Webdevs are aware of flaws in their browser so that they have to hack up a bunch of javascript in order to safely login instead of cooperating with the browser developers, which are their employees. On the other side chromium devs need to develop quirks/hacks for specific sites in order to support their bloated javascript hacks (: I find it bizzare.

shadowgovt 4y ago
It's not flaws in the browser; it's flaws in the design of HTML and CSS (i.e. "Oops nobody realized that a real right bastard could bend the static rendering tools to make this happen; well that's a problem"). I'm having difficulty sourcing the details right now, unfortunately; I believe the issue was that non-JavaScript HTML combined with CSS lets you frame-in the target site's login page but situated in such a way that the user thinks they're doing something else, and their clicks and keyboard input go into another page's content / security domain. Breaking this attack requires the framed-in site to be able to use JavaScript to detect that they were framed-in and break out. https://en.wikipedia.org/wiki/Framekiller https://en.wikipedia.org/wiki/Framekiller It's one of those situations where "This was mis-designed with insufficient eye towards how right bastards could use it, but the cat is out of the bag. We can't change the spec because it'll break legitimate uses of this technology, so this is the best option we have." Similar to how images were naively scoped to be embeddable from any web domain and then people invented pixel bugs, but you can't change the security model around image loading without breaking vast swathes of the existing web.
- moring 4y ago
  My guess would be: using CSS to place the malicious site's input files exactly where the framed site's input fields are, but "on top" (on the z axis), so the user actually inputs data into the malicious site.
  - meindnoch 4y ago
    How is this “attack” any different than simply mirroring the site? The URL bar shows the malicious site either way. If you enter your password on the malicious site, you’re pwned. Don’t need frames for that.
    - shadowgovt 4y ago
      > The URL bar shows the malicious site either way That's never been sufficient to keep bad actors out because end-users don't grok the URL bar. This attack is superior to a mirroring attack because it uses the target site's own UI resources, so it looks very legit (no need to pay someone to monitor the UI of the target site for changes and rework your exploit to attack them).

shadowgovt 4y ago

It's not flaws in the browser; it's flaws in the design of HTML and CSS (i.e. "Oops nobody realized that a real right bastard could bend the static rendering tools to make this happen; well that's a problem"). I'm having difficulty sourcing the details right now, unfortunately; I believe the issue was that non-JavaScript HTML combined with CSS lets you frame-in the target site's login page but situated in such a way that the user thinks they're doing something else, and their clicks and keyboard input go into another page's content / security domain. Breaking this attack requires the framed-in site to be able to use JavaScript to detect that they were framed-in and break out. https://en.wikipedia.org/wiki/Framekiller https://en.wikipedia.org/wiki/Framekiller It's one of those situations where "This was mis-designed with insufficient eye towards how right bastards could use it, but the cat is out of the bag. We can't change the spec because it'll break legitimate uses of this technology, so this is the best option we have." Similar to how images were naively scoped to be embeddable from any web domain and then people invented pixel bugs, but you can't change the security model around image loading without breaking vast swathes of the existing web.

moring 4y ago
My guess would be: using CSS to place the malicious site's input files exactly where the framed site's input fields are, but "on top" (on the z axis), so the user actually inputs data into the malicious site.
- meindnoch 4y ago
  How is this “attack” any different than simply mirroring the site? The URL bar shows the malicious site either way. If you enter your password on the malicious site, you’re pwned. Don’t need frames for that.
  - shadowgovt 4y ago
    > The URL bar shows the malicious site either way That's never been sufficient to keep bad actors out because end-users don't grok the URL bar. This attack is superior to a mirroring attack because it uses the target site's own UI resources, so it looks very legit (no need to pay someone to monitor the UI of the target site for changes and rework your exploit to attack them).