If I got a Bitcoin every time some websec folk started a Twitterstorm bashing CSP without proposing a viable alternative, I would be rich.
-
-
Replying to @BRIAN_____ @hillbrad and
You introduce the fragment back to the DOM, triggerring the XSS I guess. Sanitization is missing.
1 reply 0 retweets 1 like -
Replying to @kkotowicz @BRIAN_____ and
it is easier to be insecure than secure. To get security we need to change that.
1 reply 0 retweets 0 likes -
Replying to @slekies @kkotowicz and
we should make insecure things hard/impossible and secure ways easy and convenient.
1 reply 0 retweets 2 likes -
Replying to @slekies @kkotowicz and
remove everything that causes vulns (innerHTML) and provide good alternatives
2 replies 0 retweets 1 like -
Replying to @slekies @kkotowicz and
I vote for an innerHTML with ES6 templates: somediv.setInnerHTML`<b data-x=${x}>${someText}</b>`
3 replies 1 retweet 1 like -
browser can do context-aware escaping, and converting existing innerHTML users to this seems doable
1 reply 0 retweets 0 likes -
Replying to @tehjh @kkotowicz and
you mean manually or automatically converting?
1 reply 0 retweets 0 likes -
Replying to @slekies @kkotowicz and
I was thinking of manually - but I think for a developer, the conversion would be pretty easy
1 reply 0 retweets 0 likes -
if you can do it automatically, you can probably already scan for potential innerHTML XSS anyway?
2 replies 0 retweets 0 likes
although I guess there's a difference in value between finding potential XSS and blocking it
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.