if the API does not fullfill the needs, devs will hack around it. Also innerHTML is not a safe, hardened API.
-
-
... and is the source of countless vulnerabilities we otherwise wouldn't have. We can't let it happen again.
-
Also, saying that hardening APIs is bad because "frameworks can work around it" is incredibly short-sighted.
-
I am not saying that at all. Just saying we need to take this into account to not get it wrong.
-
I can show you dozens of examples where the current behavior of innerHTML led to hacks in libraries.
-
every single one is a CSP bypass btw
-
Not really; it's incompatible with one particular way to do CSP ('strict-dynamic') and is easy to fix.
-
not only strict-dynamic, also unsafe-eval, which is required for most frameworks.
-
and it is not easy to fix ;-).
- 7 more replies
New conversation -
-
-
OK, and how would you have done ng-csp differently?
-
I'll bite: if your JS FW bypasses platform restrictions you either fail closed or reimplement them yourself.
-
So for Angular, just don't implement ASTInterpreter or require nonces/hashes for expressions.
-
If they hadn't implemented it, authors wouldn't have been able to use CSP. How is this different?
-
I don't think ng-csp did any "harm" to users. On the contrary, it allowed authors to adopt (a version of) CSP.
-
Yeah, and this mentality of bypassing security mechanisms also gave us template injections.
-
What? That makes no sense :-). Template Injections existed before ng-csp.
-
It's just an example of how the approach of "let's make it work despite security restrictions" is harmful.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.