Live data from Hacker News

Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

nullcathedral.com

41–50 of 81 posts

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#41
post #39

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 think the problem is what is an image? 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 bigg…

> What I would like to see is the ability to put a that would allow the document to replace requests for url with the embedded data

multipart/related already exists.

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#42
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?

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#43
post #39

Earlier quoted context omitted.

I think the problem is what is an image? 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 bigg…

> What I would like to see is the ability to put a that would allow the document to replace requests for url with the embedded data multipart/related already exists.

> multipart/related already exists.

Which web browsers render multipart/related correctly served over https?

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#44
post #39

Earlier quoted context omitted.

I think the problem is what is an image? 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 bigg…

Why on earth does the HTML sanitiser allow blacklisting?! That can't ever be safe to use, the set of HTML elements can always change.

I mean, at least they eventually came to their senses, but it does not inspire confidence!

https://developer.chrome.com/blog/sanitizer-api-deprecation/

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#45
post #43

Earlier quoted context omitted.

> What I would like to see is the ability to put a that would allow the document to replace requests for url with the embedded data multipart/related already exists.

> multipart/related already exists. Which web browsers render multipart/related correctly served over https?

What is stopping them from doing so instead of going with a NIH solution?

Never mind the context is e-mail, which is not served to a browser over HTTPS.

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#46

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.

Put it in an iframe with a Content-Security-Policy header?

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#47
post #43

Earlier quoted context omitted.

> multipart/related already exists. Which web browsers render multipart/related correctly served over https?

What is stopping them from doing so instead of going with a NIH solution? Never mind the context is e-mail, which is not served to a browser over HTTPS.

Got it: So none.

As to why I prefer one thing that doesn’t exist over another thing that doesn’t exist depends on my priors. You might as well be asking my opinion and making fun of it before you know the answer.

What do you think the impact would be if Content-Location: would be if it suddenly gained the interpretation I suggest?

What do you think a script in the package can do to reference a part of the URL is constructed by code?

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#48

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…

[deleted]

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#49
post #6

Earlier quoted context omitted.

Some of the big providers already do this, notably Apple and Gmail: https://www.litmus.com/blog/gmail-prefetching-images

Gmails prefetch is terrible for privacy because it honors http cache headers, which means tracking companies simply use a "no-cache, must-revalidate" header to defeat it.

Which is completely stupid since images in an email should never change.

Re: Roundcube Webmail: SVG feImage bypasses image blocking to track email opens

#50

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…

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.
Post reply on HN