This is great for pranks: you send a serious looking email to someone, and then they forward it to someone else thinking they sent some chart or whatever but the next receiver instead sees another picture of your choosing
Or spearphishing. Send a secretary something that looks like a nice business proposal, then when she forwards it to her boss it's a link to some XSS attack.
Should be the other way around. You forward an email that's "obviously" spam, and then the abuse guys go "what do you mean, this is a regular project status update!"
you can use it to send "for your eyes only" stuff.
example: send an image to Mary and tell her not to send it to anyone else. She inevitably sends it to someone else, but the image magically changes to another image that says a message, maybe it says "DAMN IT MARY, I SAID DON'T SEND IT TO ANYONE ELSE!"
TL;DR: A series of markup and styling hacks that exploit HTML interpretation quirks of various web email services can be hacked to intentionally vary message appearance between services. Coupled with forwarding, which further transforms the email using service-specific quirks, you can make a game where different paths of forwarding across services trigger different appearances.
Fun hack! I feel like there should be some clever practical applications but I'm drawing a blank.
I wouldn't call that an anti-pattern, it prevents people you forwarded the mail to from easily unsubscribing you from the mailing list. They aren't subscribed, they shouldn't be able to unsubscribe.
> I feel like there should be some clever practical applications but I'm drawing a blank.
You could maybe make some sort of email analytics where you could guess the email client of the readers. Use a different background 1x1 gif image for each one then check your logs.
If you're in the email marketing business having to create and test email templates, this could actually be a very practical exercise and a team building game at the same time, I think. These bugs are a serious pain point sometimes for folks on deadlines. I could see making a sort of perpetual internal game out of this to make the job more fun and incentivize documenting new bugs found.
I remember reading Silicon Valley company being frustrated with whatever emails they had sent on company policy being forwarded to journalists (Kara Swisher??) . One hack they came up with was to slightly reword every email slightly to identify who did it.
Maybe - this solution would help in figuring out who the leakers are!
Sad situation? I'd say it's limited for security and user comfort. I can't say I've ever felt HTML emails beyond basic text formatting and links improved my life.
How is Gmail not supporting 'box-shadow' or ignoring 'display: none;' but allowing 'display: none !important;' a security feature? Not supporting classes? Why does AOL messes with inline URLs (so that they stop working)?
This article is full of examples that are obviously bugs. And worst - it's all neither documented nor standardised.
This is sadly misinformed. Having had to create business emails in the past, it's frankly a nightmare, and I can't agree with anyone who doesn't see that.
There are some good reasons why email clients do modify HTML: security is one, but they also have to make sure malformed HTML can't break the rest of the page.
There are also reasons why they don't publish clear documentation on what they do to it, but this mostly means huge headaches for anyone who tries to create HTML email.
> they also have to make sure malformed HTML can't break the rest of the page
What do you mean? That's the point of iframe, so the email content cannot break email. We have object urls[1], and it's really not super hard to put emails into a different url to simply iframe src="" it.
My first thought it that you may be looking at what is feasible today vs what was feasible for email clients (web or client) since they've been supporting HTML email. Email has been around a long time, and thinking of email as being a vector for security concerns has been a topic for even longer than consideration of browsers as a security concern because while you can "be smart" about where you browse, you can't "be smart" about what email you receive. Email that positions elements over portions of the email client or screen scrapes your email is a big deal, obviously.
Also, I am not saying that this was the only way to mitigate this risk (Apple Mail seems to pretty much use an iframe in their client, whereas other email clients still munge the HTML (Outlook, Eudora, Lotus, etc). But it is the way that many did choose, and I can understand why whether or not I agree with how they did it.
iframes have a number of real world usability problems. One example is that iOS ignores any sizing of the iframe, automatically growing it to fit its content, which could easily mangle the rest of your layout.
As long as they're on the same domain, you should be able to reach into the child iframe. Used to be a common technique for handling file upload progress before AJAX support for uploading became commonplace.
The child can reach up to the parent via JS, too, but you'd want to sanitize any JS in an email anyways.
One challenge many services face when sending emails is that you often want to log a user into the account if they've clicked in from an email – after all, if they have access to the email account, they can usually reset the password.
But the rub is always the propensity for users to forward on those same emails. If they do, then the second recipient gets control of the first recipient's account, and that's rarely the intention of the first recipient/forwarder.
I haven't had a chance to dive in enough, but I wonder if a technique like this could effectively swap tokenized links with generic links (even if you're just swapping 'display' rules) when a message is forwarded. You might have to use different message style/markup output depending on which service you're sending the message to, but my read of this article is that it's not a ridiculous thought.
Ironically, Lotus Notes Webmail is the only client I have seen so far that actually uses iframes to display HTML emails. If webmails just could embed the HTML content into an iframe with the proper sandbox attributes... nods off and dreams
Wow, you could embed entire videos with the data: uri, or run entire web apps with inline javascript with Lotus Notes if they don't sanitize it. Or completely breach their privacy by scanning their LAN for webcam URLs or taking screenshots with WebGL textures using Nvidia driver bugs... nods off and dreams
When the sandbox attribute is present, and it will:
* treat the content as being from a unique origin
* block form submission
* block script execution
* disable APIs
* prevent links from targeting other browsing contexts
* prevent content from using plugins (through <embed>, <object>, <applet>, or other)
* prevent the content to navigate its top-level browsing context
* block automatically triggered features (such as automatically playing a video or automatically focusing a form control)
I'd say alone blocking scripts, form submits, preventing links to change other contents and checking if there's behavior stuff in the CSS (which facilitates Javascript injection) is enough to have a secure webmail display. Responsive webmails \o/
Oh man, that is a dream. I had no idea that this was a thing. Too bad iframes themselves are kind of tricky to size correctly or I'd be using this willy-nilly. Skip sanitizing HTML and use a full sandboxed HTML iFrame for every comment on a user forum!
> Too bad iframes themselves are kind of tricky to size correctly
You could use an injected JS (postMessage with the iframe window height) and update the iframe height from the outside. And for the content you should just strip any script tags so you can safely allow scripting.
You should strip script tags in any case so that someone cannot use an API call which outputs raw comments as a delivery vector.
Also, you're putting users without sandbox attribute support on risk of being exploited... so you'd have to switch between two paths for display.
I don't know if you can take advantage of the random Nvidia texture leak in Linux with WebGL (I've seen it done with OpenGL), but yes. Internet users typically need to have at least some trust in the sites they visit because indeed, bad sites can do bad things to your privacy.
This would be great for an email marketing campaign. You could probably get a lot of people to refer their friends just for the opportunity to see some cool animation or graphics.
I love things that exploit the oddities of the landscape to do artsy/funky things; far more interesting than finding yet another way to trick someone into installing a password stealer.
This reminds me of the old concept of "tab damage"[1] on usenet/mailing lists. People used to leave little "devices" in their signatures that based on this that would point to the number of times a message had been forwarded or quoted, because client software would typically indent the quoted message.
This can leak the user's client by changing links per client.
Make a link per identifiable client, show only the one for the current client, and give each link a post/get parameter identifying the client. Quite easy to do, but a lot of work to have broad client support.
Tada! I now know you read your email on your [obscure and bugged client], which is susceptible to [this and that exploit].
This is an exploit as well, just a different kind. It doesn't require any programming errors in the clients, instead it relies on the non-standardization of clients.
