3 ms·

I doubt it's as easy to resolve as you think... a. That would barely mitigate the problem; it might stop some of the goofy alert() hacks from people messing ar

I doubt it's as easy to resolve as you think... a. That would barely mitigate the problem; it might stop some of the goofy alert() hacks from people messing around, but the others are just going to use the exploit to include an external .js file. Even if your meta-tag would require all JS code to be in the <HEAD>, someone could have used this exploit to create an iFrame which then contained the JS. Or create a meta-refresh tag that redirects to the page with the exploit. The possibilities are endless. b. If someone figures out how to break the character escape jail, then they're going to be able to write a </noscript_within> tag.

chime 16y ago
If a user can do an alert(), they can pretty much do anything. JS has no security-levels except domain restrictions. > someone could have used this exploit to create an iFrame But this exploit wouldn't even run. My browser would only run JS on youtube.com from external JS files. YouTube devs could put <script> within their php pages and it would do nothing, let alone random users putting <script> tags in comments. Only way to run ANY JS on youtube.com would be to load an external .js file. If this meta-tag was present, you cannot load an external JS file unless it was defined in the <head>. I really fail to see a way to break out of this shell. Adding a <script>, <meta>, <link>, <head> tag below the initial <head></head> would not work if this mode was turned on. Well-designed sites don't add meta/link tags outside of the <head> anyway. So I don't think it is asking for too much. > If someone figures out how to break the character escape jail I agree but that is almost certainly preventable. Right now, JS can be introduced via so many ways (<script>, on-events, javascript:) and web devs have to protect against all of them. I remember in one of the MySpace XSS attacks, IE allowed "<scri\npt>" to execute despite the new-line. Browsers will look for string <noscript_within> as start and </noscript_within> as end. So will web-devs. No partial-lines, no attributes, no nothing. RegEx doesn't fail.
- jacquesm 16y ago
  > YouTube devs could put <script> within their php pages Youtube is written in PHP ? I thought it was mostly python.
  - chime 16y ago
    You're right. I was relying on really old data. http://mail.python.org/pipermail/python-dev/2006-December/070323.html http://mail.python.org/pipermail/python-dev/2006-December/07...
- sounddust 16y ago
  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

chime 16y ago

If a user can do an alert(), they can pretty much do anything. JS has no security-levels except domain restrictions. > someone could have used this exploit to create an iFrame But this exploit wouldn't even run. My browser would only run JS on youtube.com from external JS files. YouTube devs could put <script> within their php pages and it would do nothing, let alone random users putting <script> tags in comments. Only way to run ANY JS on youtube.com would be to load an external .js file. If this meta-tag was present, you cannot load an external JS file unless it was defined in the <head>. I really fail to see a way to break out of this shell. Adding a <script>, <meta>, <link>, <head> tag below the initial <head></head> would not work if this mode was turned on. Well-designed sites don't add meta/link tags outside of the <head> anyway. So I don't think it is asking for too much. > If someone figures out how to break the character escape jail I agree but that is almost certainly preventable. Right now, JS can be introduced via so many ways (<script>, on-events, javascript:) and web devs have to protect against all of them. I remember in one of the MySpace XSS attacks, IE allowed "<scri\npt>" to execute despite the new-line. Browsers will look for string <noscript_within> as start and </noscript_within> as end. So will web-devs. No partial-lines, no attributes, no nothing. RegEx doesn't fail.

jacquesm 16y ago
> YouTube devs could put <script> within their php pages Youtube is written in PHP ? I thought it was mostly python.
- chime 16y ago
  You're right. I was relying on really old data. http://mail.python.org/pipermail/python-dev/2006-December/070323.html http://mail.python.org/pipermail/python-dev/2006-December/07...
sounddust 16y ago
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