Yes, this isn't even the first cross-domain leakage attack on iframes using CSS. [0] There were similar issues with how hit testing was implemented for `document.elementFromPoint()`[1], and probably tons of other things I'm forgetting.
Ideally cross-origin framing would have been disallowed by default but frames were added to the spec before people spent a lot of time thinking about the same-origin-policy implications.
That's similar to what Kaminsky proposed with Iron Frame[0], but obviously it'd have to be opt-in. Applying Iron Frame-like rendering to all iframes would break a lot of content.
Generally if you have a CSP without `unsafe-inline` you'd have have a policy that would restrict all subresources (`default-src 'none'`,) then punch holes in the policy by resource type (`img-src`, `script-src`, etc.)
For ex. if you have a proper CSP with `default-src 'none'` you should be fine so long as you didn't allow `*` or `unsafe-inline` in any of the other `<X>-src` directives.
They shouldn't. These examples all rely on being able to cause an image load on a host the attacker controls if the CSS rule is applied. reddit blocks stylesheets that reference off-site resources. See https://github.com/reddit-archive/reddit/blob/master/r2/r2/l...
> The screenshot of their app on the iOS App Store shows a bunch of credible logos of their mentions, but then quotes "VyperVPN is the best service on the market" as coming from a reddit comment by a random user. Questionable tactic.
Interesting! I haven't spent much time looking at OS X internals, but I'll remember this for next time. Have any resources for other OS X quirks like this?
To JetBrains' credit they were very responsive throughout the disclosure process. I received a reply to my initial report in under two hours. Generally response times are measured in days unless you know someone in the company.
They also gave me diffs against intellij-community master so I could verify their fixes were sound, and they were generally receptive to my feedback.
No, all that's necessary to trigger it is browsing to a page containing attacker-controlled JavaScript or Flash. The browser on your own computer would be connecting to the server on your own computer, and firewalls tend to only block external connections.
That's fair. My point was that in reality, a ton of people end up doing it wrong in some way or another. You should cover your bases and keep your systems up to date with security patches regardless of how segregated you believe they are.
Any number of things can out you as a fake. Whether or not the request's Accept-Encoding has sdch, can help you figure out if something's Chrome.
You can also abuse parsing quirks to figure out which rendering engine's being used, or just try to use request-generating features that shouldn't be present in whatever browser you're saying you are (<svg>, <video>, styling on engine-specific psuedoelements, etc.)
Here's an example[1] using just HTML+CSS that will request a different image depending on whether you use a webkit or gecko derivative. If you use neither, no image will be requested. Someone who says they're Chrome but requests Firefox's image is immediately outed as a liar.
I believe Mario Heiderich also posted some stuff using webkit's styleable scrollbars that could be used for fingerprinting screen sizes and how large certain elements are when rendered.
The list goes on, but my point is that fingerprinting at the rendering / layout engine level is trivial, so you're better off being legitimately ordinary if you're worried about fingerprinting.
Ideally cross-origin framing would have been disallowed by default but frames were added to the spec before people spent a lot of time thinking about the same-origin-policy implications.
[0]: https://www.contextis.com/resources/white-papers/pixel-perfe... [1]: http://blog.saynotolinux.com/blog/2014/02/05/whats-that-smel...