CSS: the bomb inside your inbox
56 points by refp
56 points by refp
I'd love to not deal with HTML email again. If THIS is the straw that makes webmail providers stop supporting it, I'll laugh. Then thank Gareth Heyes, because this is a good find.
They won't, though; they'll retool to make it harder to exploit.
I'm honestly surprised this hasn't come up sooner. But I've spent time in the general vicinity of this issue and never spotted it, so I shouldn't be surprised.
By my read, this makes all the webmail things unsafe to use with at least 80% of my inbox. And I wonder if it doesn't also make things like the gmail mobile client unsafe, too.
I'm honestly surprised this hasn't come up sooner. But I've spent time in the general vicinity of this issue and never spotted it, so I shouldn't be surprised.
When first clicking on a link to this article I quite literally thought "oh, just another CSS tracking pixel sort of thing" perhaps at best with a touch of "I guess someone didn't sanitize all these non-obvious XSS attacks".
Never would I have imagined things such as (ab)using html-labels to carry such an impactful attack vector.
<frame>...</frame>?
Perhaps this is the resurrection of using html-frames as an annoyingly awkward security barrier, where at least attacker injected css/content would be limited to whatever is also in that <frame>.
History doesn't repeat itself, it frames... perhaps.
The labels thing is both brilliant and infuriating. I’m not sure how you’d fix it, except to strip label tags from the content which seems like no big deal, but I don’t know about the accessibility implications.
Yeah, as with most things sanitizing content is the fix for most things but.. the fact that the "what we need to sanitize" list is growing longer and longer makes one question if we should simply revert back to text/plain and "only" worry about weird utf-8 points.
It seriously sucks that trying to be a better citizen of the net and be good about accessibility, internationalization, etc is essentially unlocking doors and windows for burglars.
It is official: Google, the party guilty of making the Web Platform the unpredictably moving mess it is, is incapable to keep track even of the basics of what there is in the Web Platform. Hard not to treat the entirety of modern Web as malicious…
Am I dumb for assuming webmail interfaces would be rendering email content in an iframe?
You are not: RoundCube and Zimbra definitely use iframe for that.
Assuming Google does anything at all fully reasonably is a bit naive, though.
Last time I had to debug email styles in Gmail, the email content was sanitized and rendered inline (thus, it’s no wonder Gmail supports such a small and unintuitive subset of HTML/CSS in mail bodies). That was some time ago, though.
It really is time for more people to switch to text-based email. All of these problems go away.
An attacker can see requests to the user.fm domain via a convenient access log provided by Fastmail.
I was surprised by this and couldn't figure out what he was talking about, but it turns out that you can host a website and it shows up at https://user.fm/<username>.fastmail.com, and Fastmail gives you access logs to the website.
I found a similar bug in May where I could trick Fastmail's client into loading arbitrary image URLs, but their CSP rules correctly prevented the browser from completing the request. They fixed the bug but said it wasn't a complete attack because CSP catches it, so they only awarded $100.
I wish I'd figured out the user.fm access log feature at the time because Fastmail's CSP allows the user.fm domain for the img-src rule.
I don't see it mentioned in the article, but could shadow DOM defend against this style of attack?