3 ms·

The point I'm making is that it's not as easy of a problem to resolve as you are claiming. The problem is that - as you said - there are so many different XSS

The point I'm making is that it's not as easy of a problem to resolve as you are claiming. The problem is that - as you said - there are so many different XSS vectors in the browser; if you patch one specific use case then the exploiter will just find another. Browser developers aren't avoiding this problem; they just realize how complicated it is and have to approach it slowly to do it right, and to not break compatibility. Your <noscript_within> tag is something that I'm sure every browser developer (and web app developer) has thought up at some point. It does not resolve this problem. It would only protect a site in the case that a website allowed all user input to be passed directly onto the page unedited. Your solution would require app developers to allow commenters the full range of HTML (including blink, marquee, and who knows what else) in their comments. Because once the app developer starts to try to filter the commenter's input, he's opening himself up to an exploit that allows the filtered output to contain a </noscript_within> tag. The simplest example would be an app developer who simply deleted all <marquee> tags because he/she wanted to disallow marquees. The script kiddie would just insert </noscript_<marquee>within> into his comment. The more complicated examples would be things that neither you nor I have thought of yet. That doesn't even take into account the exploit of users in legacy web apps who could potentially start passing in unclosed <noscript_within> tags (in apps which allow HTML but filter only certain tags) to disable legitimate JS later in the page, breaking the apps. Of course, it would be possible to only enable <noscript_within> based on doctype or something else, but then it's certain that some web developers will accidentally forget to do so and leave their app open to abuse. You are oversimplifying the problem. I am sure that a solution exists and XSS will eventually become a problem of the past, but the solution will be more complicated than you claim it would be.

chime 16y ago
Forget (b). I get that it may not be perfect. Why do you think (a) wouldn't work? It is as simple as disabling JS on the HTML pages. That works on all browsers already. Let's keep that + enable JS from .js files. I understand it is more complex than I'm making it out to be but isn't that better than XSS error on the world's largest sites?
- sounddust 16y ago
  The implementation of a) would be extremely complex from both a web developer and browser development viewpoint. From the web developer perspective: It's very hard to use JS without putting at least some javascript in the HTML. Loading js files is not very useful if there's no means to actually activate any of the functionality of those files. In order for your idea to work, you'd have to completely strip all HTML of anything that can reference or activate javascript: not just mouseover, but also href="javascript:xxxx()" as well. That means that the only way you could actually use javascript on a page would be to create a function that would be loaded by body_onload to add event listeners and other attributes through DOM manipulation. It would make web development so convoluted that I doubt that you'd succeed in convincing w3c or anyone else to adopt it. I think the right approach has to maintain the workflow and functionality of web development. tptacek posted an idea in the other thread that sounds like it would reduce the number of attack vectors without causing too much difficulty to the developer: include a nonce in the header and require script tags to include that nonce.
yuhong 16y ago
Yea, it would be better to allow the <noscript_within> tag to include a list of HTML tags to ignore or allow.

chime 16y ago

Forget (b). I get that it may not be perfect. Why do you think (a) wouldn't work? It is as simple as disabling JS on the HTML pages. That works on all browsers already. Let's keep that + enable JS from .js files. I understand it is more complex than I'm making it out to be but isn't that better than XSS error on the world's largest sites?

sounddust 16y ago
The implementation of a) would be extremely complex from both a web developer and browser development viewpoint. From the web developer perspective: It's very hard to use JS without putting at least some javascript in the HTML. Loading js files is not very useful if there's no means to actually activate any of the functionality of those files. In order for your idea to work, you'd have to completely strip all HTML of anything that can reference or activate javascript: not just mouseover, but also href="javascript:xxxx()" as well. That means that the only way you could actually use javascript on a page would be to create a function that would be loaded by body_onload to add event listeners and other attributes through DOM manipulation. It would make web development so convoluted that I doubt that you'd succeed in convincing w3c or anyone else to adopt it. I think the right approach has to maintain the workflow and functionality of web development. tptacek posted an idea in the other thread that sounds like it would reduce the number of attack vectors without causing too much difficulty to the developer: include a nonce in the header and require script tags to include that nonce.

yuhong 16y ago

Yea, it would be better to allow the <noscript_within> tag to include a list of HTML tags to ignore or allow.