71–80 of 172 posts
Earlier quoted context omitted.
Finally, a good use case for AI.
Yeah, using a kilowatt GPU for string replacement is going to be the killer feature. I probably shouldn't even be joking, people are using it like this already
Earlier quoted context omitted.
That's the whole point of the setHTML. How would I set a header level using textContent?
The traditional way: separating data and code document.createElement("h1").textContent = `Hello, ${username}!` If you allow in the setHTML configuration or use the default, users with the tag in their username also always get it rendered as markup
This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But…
Ideally you should be able to set a global property somewhere (as a web developer) that disallows outdated APIs like `innerHTML`, but with the Big Caveat that your website will not work on browsers older than X. But maybe there's web standards for that already, backup content if a browser is considered outdated.
So you can still inject or ... etc into your username, in the given example Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?
Anyone who wants to provide some level of flexibility but within bounds. Say, you want to allow and in a forum post but not . It's not too difficult to imagine uses.
So you can still inject or ... etc into your username, in the given example Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?
This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But…
Ideally you should be able to set a global property somewhere (as a web developer) that disallows outdated APIs like `innerHTML`, but with the Big Caveat that your website will not work on browsers older than X. But maybe there's web standards for that already, backup content if a browser is considered outdated.
Earlier quoted context omitted.
[dead]
BTW, HTML allows inline SVG with an XML-flavored syntax that interprets and differently. It's a goldmine for sanitizer escapes. There are completely bonkers syntax switching and error recovery rules that interact with parsing modes (there's even an edge case where a particular attribute value switches between HTML and XML-ish parsing rules). Don't even try to allow inline from untrusted sources! (and then you still m…
A rather deceptive title, given that 'innerHTML' isn't going away.
Earlier quoted context omitted.
> but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. If that's true, seems like it's still a security risk given what you can do with CSS these days: https://news.ycombinator.com/item?id=47132102
You can use selectors to gain some information about things like input fields, e.g. https://www.invicti.com/blog/web-security/private-data-stole... Or I guess you could completely restyle and change the text of UI elements so it looks like the user is doing one thing when they're actually doing something completely different like sending you money
Earlier quoted context omitted.
because the "unsafe" suffix conveys information to the reader, whereas `innherHTML` does not?
Any potential reader should be familiar with innerHTML.
Or how any potential driver is familiar with seat belts which is why everybody wears them and nobody’s been thrown from a car since they were invented.