Comment by chime | Hacker News Reader

Comment by chime | Hacker News Reader

Parent Full thread

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.

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.

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?

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.

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

> YouTube devs could put <script> within their php pages

Youtube is written in PHP ? I thought it was mostly python.

You're right. I was relying on really old data.

http://mail.python.org/pipermail/python-dev/2006-December/07...

Reply on news.ycombinator.com