I am trying to read as less _online_ as possible nowadays. I essentially have dovecot in my crontab, and read it off roundcube. It's been working great, RoundCube is dead simple to setup and use, the UI and search are very fast.
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so.
Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon.
I feel like the bigger issue is the W3 (nee Google). The new HTML Sanitizer[2] interface does nothing, but some VP is somewhere patting themselves on the back for this. We don't need an object-oriented way to edit HTML, we need the database of changes we want to make.
What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data, support what we can, then just turn off networking for things we can't. If networking is enabled, just ignore the pre-cache tags. No mixing means no XSS. Networking disabled means "failures" in the sanitizer is that the page just doesn't "look" right, instead of a leak.
Until then, the HTML4-era solution was a whitelist (instead of trying to blacklist/block things) is best. That's also easier in a lot of ways, but harder to maintain since gmail, outlook, etc are a moving target in _their_ whitelists...
Slightly related, but fraudsters love using .svg attachments, typically the mails purport to be for an invoice which you need to log into your Microsoft account to be able to “securely” view.
I’m not sure if Exchange Online doesn’t scan them or something, but I landed up making a rule which blocks all emails with either .svg or .htm(l) attachments and to notify me when blocked.
Happens a couple of times per month for the our small company, no false positives yet.
I know someone who embeds an SVG of his signature in their emails. Looks pretty cool, renders inline, and it's sad that the state of things means they'll probably have to remove it because it triggers spam filters.
Not disputing the article, nor insinuating that there's some ulterior motive, but it's curious that this blog has only one post; and the About page suggests a lengthier history (with references to what would have been previous posts).
SVGs are just the tip of the iceberg of how hard it is to sanitize email content. There aren't any purpose-built good libraries for email sanitization either. Something that would handle SVG, CSS, HTML, everything.
You give the developer time to develop a patch. Once the patch is out, attackers can already deduce the vulnerability by looking at what changed and at that point you either want to immediately install the patch or you want to know what the vulnerability actually is so you can do something to mitigate it if there is some reason you can't immediately install the patch.
From reading a little bit of the code it sounds like Roundcube's sanitizer is much closer to a blacklist than a whitelist. Any attempt to sanitize HTML with a blacklist is doomed to failure. Even if you read the current HTML spec (including referenced specs like SVG) and do a perfect job there are additions over time that you will be vulnerable to.
Probably any unknown element attribute pair should be stripped by default. And that's still not considering different "namespaces" such as SVG and MathML that you need to be careful with.
SVGs are such an amazing attack vector. Nearly every webapp I've seen that allows image or SVG uploads is vulnerable to XSS. If the Roundcube implementation allows for remote image fetching, it's probably worth checking it for XSS vulnerabilities.
Also: what's the legal status of this kind of tracking? How does it jibe with the GDPR?
22 comments
[ 4.4 ms ] story [ 48.5 ms ] threadI am trying to read as less _online_ as possible nowadays. I essentially have dovecot in my crontab, and read it off roundcube. It's been working great, RoundCube is dead simple to setup and use, the UI and search are very fast.
Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon.
I feel like the bigger issue is the W3 (nee Google). The new HTML Sanitizer[2] interface does nothing, but some VP is somewhere patting themselves on the back for this. We don't need an object-oriented way to edit HTML, we need the database of changes we want to make.
What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data, support what we can, then just turn off networking for things we can't. If networking is enabled, just ignore the pre-cache tags. No mixing means no XSS. Networking disabled means "failures" in the sanitizer is that the page just doesn't "look" right, instead of a leak.
Until then, the HTML4-era solution was a whitelist (instead of trying to blacklist/block things) is best. That's also easier in a lot of ways, but harder to maintain since gmail, outlook, etc are a moving target in _their_ whitelists...
[1]: https://github.com/geocar/firewall.js
[2]: https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...
I’m not sure if Exchange Online doesn’t scan them or something, but I landed up making a rule which blocks all emails with either .svg or .htm(l) attachments and to notify me when blocked.
Happens a couple of times per month for the our small company, no false positives yet.
Probably any unknown element attribute pair should be stripped by default. And that's still not considering different "namespaces" such as SVG and MathML that you need to be careful with.
Also: what's the legal status of this kind of tracking? How does it jibe with the GDPR?
https://www.caniemail.com/features/html-svg/