4 ms·

By "I wish that emails could just work like everything else on the web" I meant modern web HTML/CSS - I was replying to the GP - not the full set of browser cap

by whakim 5y ago

By "I wish that emails could just work like everything else on the web" I meant modern web HTML/CSS - I was replying to the GP - not the full set of browser capabilities such as Javascript. I suppose it's possible you'd also want to exclude certain CSS abilities, but at that point you're now diverging from the web CSS spec which isn't ideal either.

fomine3 5y ago
Web standard is continuously evolving but email don't need most of them. I think whitelist approach is better than blacklist for email.
- whakim 5y ago
  Yes, but then who maintains the whitelist? What's to stop individual email providers from deciding they do/don't like certain standards? I agree that email doesn't need much of the CSS spec, but nor do the vast majority of web sites and yet we don't like it when browsers aren't standards-compliant...
  - fomine3 5y ago
    HTML/CSS is designed to be safe for web by browser vendors and working groups. Unused HTML/CSS feature is fine as long as it's not vulnerable, but blacklist for email is problem because new feature is not designed to be safe for email. Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
    - whakim 5y ago
      Can you share some CSS vulnerabilities that would work in email but not in a browser? I can certainly think of CSS vulnerabilities that would not work in email because email can't execute javascript, but can't come up with the reverse off the top of my head. Genuinely curious here.
      - fomine3 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. * iframe content inside message is editable after message sent. * Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident) * Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
        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.
    - philistine 5y ago
      I don't think there's any HTML or CSS that is problematic in an email. The problem is Javascript.
      - speleding 5y ago
        The surface of HTML+CSS is pretty big by now. Perhaps you could use CSS to restyle the "From" address: hide the original content and use an :after property to put "$bank_name" there. Perhaps you can generate a unique @font url for each user to track opening of messages. Just two things of the top of my head that maybe won't work, but it would probably be a cat and mouse game for a while when security researchers start poking at it.

by whakim 5y ago

fomine3 5y ago

Web standard is continuously evolving but email don't need most of them. I think whitelist approach is better than blacklist for email.

whakim 5y ago
Yes, but then who maintains the whitelist? What's to stop individual email providers from deciding they do/don't like certain standards? I agree that email doesn't need much of the CSS spec, but nor do the vast majority of web sites and yet we don't like it when browsers aren't standards-compliant...
- fomine3 5y ago
  HTML/CSS is designed to be safe for web by browser vendors and working groups. Unused HTML/CSS feature is fine as long as it's not vulnerable, but blacklist for email is problem because new feature is not designed to be safe for email. Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
  - whakim 5y ago
    Can you share some CSS vulnerabilities that would work in email but not in a browser? I can certainly think of CSS vulnerabilities that would not work in email because email can't execute javascript, but can't come up with the reverse off the top of my head. Genuinely curious here.
    - fomine3 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. * iframe content inside message is editable after message sent. * Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident) * Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
      - 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.
  - philistine 5y ago
    I don't think there's any HTML or CSS that is problematic in an email. The problem is Javascript.
    - speleding 5y ago
      The surface of HTML+CSS is pretty big by now. Perhaps you could use CSS to restyle the "From" address: hide the original content and use an :after property to put "$bank_name" there. Perhaps you can generate a unique @font url for each user to track opening of messages. Just two things of the top of my head that maybe won't work, but it would probably be a cat and mouse game for a while when security researchers start poking at it.