3 ms·

How about just don't use innerHTML? It's slow, insecure and lazy. We don't need Google pushing more proprietary fake web standards in their IE6 browser. They sh

How about just don't use innerHTML? It's slow, insecure and lazy. We don't need Google pushing more proprietary fake web standards in their IE6 browser. They should fix the existing issues in CSP (like WebAssembly being completely broken) before adding new crap to it.

arkadiyt 7y ago
There's a lot more XSS sinks than innerHTML, and "just don't do it" isn't helpful security engineering. Mike Samuel published a great post with lots of context on the design of Trusted Types at Google and why they think it works well: https://github.com/w3c/webappsec-trusted-types/wiki/design-history https://github.com/w3c/webappsec-trusted-types/wiki/design-h...
- rubbingalcohol 7y ago
  It's a lot of handwaving. So Google improperly saved HTML into database string fields and now needs to figure out how to safely render it in a template. We don't need a new web "standard" to help them wallpaper over their first-party bugs. For the longest time Firefox add-on developers were prohibited from submitting extensions with eval or innerHTML precisely because it is ~not safe~! Adding a bunch of browser-enforced regex checks to your strings is the wrong solution here. The solution is to not write code that writes itself.
  - rictic 7y ago
    Trusted Types lets you do exactly this! You explicitly list the trusted types policies that you allow on your page, and if none of them declare the createHTML method then there is no way to set innerHTML (even inside some a new version of some obscure dependency of a dependency, or in some script that an intern plopped into the page, or in some five year old code that seemed reasonable at the time that you've totally forgotten about... (not like that happened to me recently))
  - jamesgeck0 7y ago
    > So Google improperly saved HTML into database string fields and now needs to figure out how to safely render it in a template. FWIW, "store anything, sanitize at render time" is the preferred approach for some popular web frameworks, including Rails.
    - rubbingalcohol 7y ago
      And that's fine. To the extent that stored data represents a security risk, sanitization can and should be done on the server side.
zemnmez 7y ago
because there are way, way more ways of getting XSS than innerHTML. if innerHTML was the only way to get XSS, XSS would have been solved by React / Angular. Consider <a href=xx/> – if xx is `javascript:alert(1)` it executes code, even if you generate this DOM node without even touching HTML.
- rubbingalcohol 7y ago
  Content Security Policy (which Trusted Types is taped on to) already provides for blocking unsafe-eval, which would prevent this type of attack. No need for vendor specific bloat.

arkadiyt 7y ago

There's a lot more XSS sinks than innerHTML, and "just don't do it" isn't helpful security engineering. Mike Samuel published a great post with lots of context on the design of Trusted Types at Google and why they think it works well: https://github.com/w3c/webappsec-trusted-types/wiki/design-history https://github.com/w3c/webappsec-trusted-types/wiki/design-h...

rubbingalcohol 7y ago
It's a lot of handwaving. So Google improperly saved HTML into database string fields and now needs to figure out how to safely render it in a template. We don't need a new web "standard" to help them wallpaper over their first-party bugs. For the longest time Firefox add-on developers were prohibited from submitting extensions with eval or innerHTML precisely because it is ~not safe~! Adding a bunch of browser-enforced regex checks to your strings is the wrong solution here. The solution is to not write code that writes itself.
- rictic 7y ago
  Trusted Types lets you do exactly this! You explicitly list the trusted types policies that you allow on your page, and if none of them declare the createHTML method then there is no way to set innerHTML (even inside some a new version of some obscure dependency of a dependency, or in some script that an intern plopped into the page, or in some five year old code that seemed reasonable at the time that you've totally forgotten about... (not like that happened to me recently))
- jamesgeck0 7y ago
  > So Google improperly saved HTML into database string fields and now needs to figure out how to safely render it in a template. FWIW, "store anything, sanitize at render time" is the preferred approach for some popular web frameworks, including Rails.
  - rubbingalcohol 7y ago
    And that's fine. To the extent that stored data represents a security risk, sanitization can and should be done on the server side.

zemnmez 7y ago

because there are way, way more ways of getting XSS than innerHTML. if innerHTML was the only way to get XSS, XSS would have been solved by React / Angular. Consider <a href=xx/> – if xx is `javascript:alert(1)` it executes code, even if you generate this DOM node without even touching HTML.

rubbingalcohol 7y ago
Content Security Policy (which Trusted Types is taped on to) already provides for blocking unsafe-eval, which would prevent this type of attack. No need for vendor specific bloat.