3 ms·
> * Any way that reference external resource like css url() can be used as beacon. It should be blockable by client like image, but thinking how it affect is di
by whakim 5y ago
> * Any way that reference external resource like css url() can be used as beacon. It should be blockable by client like image, but thinking how it affect is difficult if all tags are allowed.
You can already use url() to load background images - seems like this is a solved vector.
> * iframe content inside message is editable after message sent.
Does this really increase the attack surface area, since you can't execute javascript from the iframe?
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
No, because that's not in the HTML/CSS spec and modern browsers don't support it.
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
- fomine3 5y ago> You can already use url() to load background images - seems like this is a solved vector. Background image with url() is very easy to be whitelisted because it's very similar to <img> tag. > Does this really increase the attack surface area, since you can't execute javascript from the iframe? Sorry, this concern isn't about security for browsers, but for text editable email without indication. Maybe you can argue that it's not a problem because external image is already replaceable, but IMO it's more problematic. > No, because that's not in the HTML/CSS spec and modern browsers don't support it. Blacklist approach means that any tags just work unless explicitly specified on blacklist. "Not in spec" won't help. > Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail. That's thanks to whitelist approach.