6 ms·

XSS is such a huge deal and yet I don't understand why browser makers/w3c etc. haven't agreed on any solutions yet. a. Have a meta-tag (or something in the <he

• deleted 16y ago
  [deleted]
  • deleted 16y ago
    [deleted]
• chacha102 16y ago
  But what if the person simply broke out of the <noscript_within> tag? <noscript_within><div id="comments"><div id="comment"></noscript_within><script src="myfile.js"></script></div></div></noscript_within> Probably the best method for this is giving the amount of characters are in the <noscript_within> tag. I don't believe this would break caching, as the length only changes when the content changes.
  • exit 16y ago
    i suggested that (deleted comment), but it seems easy enough to at least scan for a closing "</noscript_within>" tag in the comment body.
    • sounddust 16y ago
      Until someone writes </noscript_within > or < /noscript_within> and your script doesn't catch it but the browser accepts it. Or one of hundreds of other small details that neither one of us has thought of yet.
      • chime 16y ago
        That's why browser makers have to agree on the acceptable usage and suggest what web devs should search/for and sanitize. Right now, browser makers do not recommend anything except "sanitize your input" and that means something completely different for each browser.
    • dasil003 16y ago
      it seems easy enough... Yes, every single XSS vulnerability is pretty easy to fix on its own. The problem is that you'll never get all of them across browsers. It's time that browser makers went back to the drawing board and came up with a base security model to cut the fat away from the basic attack footprint. Some drastic limit on the source of executable JS files, specified in an HTTP header, could be very effective.
      • chime 16y ago
        > It's time that browser makers went back to the drawing board and came up with a base security model to cut the fat away from the basic attack footprint. Some drastic limit on the source of executable JS files, specified in an HTTP header, could be very effective. Absolutely! I'm just surprised that so many people here are against any changes to the browsers while expecting that every single developer in the world ensure there's not one bug in their code. This isn't the same thing as PHP's safe_mode that never really worked as excepted. This is more like crossdomain.xml file. It is something browser makers can proactively do to improve security. Sure, web developers should keep sanitizing inputs as much as possible. And browsers should try to prevent XSS as much as possible. Why can't both work together? Why is it only the developers' problem?
        • seancron 16y ago
          I don't think people are against changes to the browsers. I think they just realize that there are many different browsers out there that each do things slightly differently. If you've ever tried to get CSS working for all possible browsers, you've probably come across cases where it works in some browsers, but not others (I'm looking at you IE6), and you have to use a hack to get it to work. Changes to browser standards occur at a much slower rate than changes to your code. Politics, competition, and disagreements on standards often get in the way. Just look at all the controversy over the HTML 5 video codec. Unless browser makers, by some miracle, agree on a common standard for browser security, there are always going to be little idiosyncrasies that occur from browser version to browser version. Just because it's secure in all the browsers you tested, doesn't mean that it's secure in the browsers you didn't test. The best solution as of right now is to develop ways of writing more secure code, with less potential for human error.
• sounddust 16y ago
  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.
• axod 16y ago
  It's not rocket science. Escaping HTML properly is a good start. Not just "Oh yeah we better disallow any <script> tags". I mean properly, escape every single character so that there is absolutely no possible way that anything can be interpreted as anything but a literal character to be displayed. <noscript_within> sounds like a good solution if you have no idea how to properly escape html. If you want to be extra sure, just send the data as JSON and build it out in the DOM as createTextNode so you're sure it's actually text and nothing else. From Reddit: >> All you need is: <script><script>PAYLOAD >> Any HTML after the second non-closed script tag survives unescaped. >> YouTube escapes the first script tag and not the second. This isn't "XSS attacks are inevitable and so hard to defend against". This is "WTF are you thinking youtube? Did you get a 12 year old to code your comment parsing code?"
  • chime 16y ago
    > It's not rocket science I know. But it isn't cakewalk either when you take Unicode/UTF etc. into consideration. Myspace, Twitter, Facebook, and now YouTube have been bitten by it, some multiple times. My point is, with so much social content being user-generated, there is absolutely no way to wall-off the user-content easily. You have to manually make sure every piece of user data is parsed and filtered, and most developers do that but it's not easy. Show me the code that allows users to enter basic HTML (<a>, <b>, <p>, <u>) while preventing the bad stuff (<script>, <body>). Now make this code allow <a> to have attributes like href, title but not onclick, onmouseout. Allow <p> to have style attributes for font-family but not width:expression(400 + "px") style because that's another way to run JS in IE. You'll quickly see how it gets difficult really quick. The solution for most sites (including reddit/HN) is to use Markdown. It's not a perfect solution but it works for sites where data entry is restricted to a few fields. YouTube is so large and has so many places where users can enter arbitrary data that it is not simple to ensure there are no bugs anywhere. Again, I don't understand how my solution (a) fails in preventing all XSS hacks that we've seen so far. Each hack worked because users could insert JS code into a form that was not properly filtered. What is harder? Making sure every single web form on the Internet has 0 sanitization bugs or adding a single meta-tag to top browsers that says "Hey, don't run any inline JS."
    • 16y ago
• tszming 16y ago
  This proved Doug Crockford is right. Security problem should be fixed in HTML5. http://www.youtube.com/watch?v=10fnZ2chEYg http://www.youtube.com/watch?v=10fnZ2chEYg
• jgrahamc 16y ago
  Or enforce script tag signing. http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-tags.html http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-t...
  • chime 16y ago
    I've read your idea before and while I have absolutely no technical issues with it, I think it requires a lot more work from everyone involved. The only use for inline scripts at the end of a webpage (right before the </body> tag) that I can think of are analytics/user-tracking scripts. Other than that, I don't see why the JS code couldn't be included in a .js file. And since JS code from .js files can load the analytics files (albeit in a different order than inline script tags), I think my (a) approach would be sufficient for the purpose of blocking XSS.
• joeyh 16y ago
  People have been focusing on the noscript tag, but I rather like the idea of something in the head that disables all javascript in body. One good idea is perhaps better than one good idea followed by one bad idea, especially when the history is already full of so many horrible ideas that got into the spec. ;) But there's also already something in html5; the iframe sandbox attribute. Among other things it can be used to disallow scripts to run in an iframe. You can read about it here. Amusingly, they suggest it may be available for widespread use in 10 years. http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox
  • chime 16y ago
    > One good idea is perhaps better than one good idea followed by one bad idea Haha. I'm sure both ideas have been proposed by many people over the years. I have definitely heard of (b) from many others. I haven't heard of anyone else mentioning (a) yet. I'm kinda surprised that everyone keeps arguing against (b) while saying nothing about why (a) won't work.
    • joe_the_user 16y ago
      I believe that I and others have mentioned objections that would include (a). 1. Take any given browser-based security check. A server that cares about security could do it, as a last step, instead without waiting for a hypothetical browser that would do the step. Worried about scripting in the body, strip script or whatever tags off as your last step. Sure, you could do it wrong but so could the browser. This wouldn't solve client security problems but that is the client's problem - it should be the clients problem. Some of the clients running in a large site are going to be compromised and the site has to deal with that separately from its own potential use as a vector for infection. 2. Take away the sites that care about security and ... you're left with the sites that don't care about security. And with these, even if you add the browser-side security, the uncaring sites would still be there and vulnerable. Sure, this division might be a little simplistic and you could cook up an argument for script signing but it still doesn't make sense to me. Implementing security in a single reliable place, your site, seems inherently better than implementing it across multiple domains you don't control. Microsoft's signed applets were a failure back in the day as I recall. Indeed, if you need something totally secure, why not try Java applets? They've already implemented inherently secure. (Java applets were not perfectly secure but at security was in Java to begin with, so it will always be much stronger than Javascript ... but we have think why Java applets were much less sucessful than Ajax applications).
• gojomo 16y ago
  Not sure about <noscript_within> going all the way to the browser -- but it might be useful as a directive to a front-end reverse-proxy, working a little like an edge-side-include but telling it to strip stray SCRIPTs, that would provide a last line of defense against. Not elegant, but perhaps by providing a separate independent layer of enforcement could prove worthwhile. Still, there's the problem of having app developers rigorously declare the SCRIPT-suppressed regions. So perhaps instead the sense should be reversed: require app-designers to rigorously declare only those narrow areas where SCRIPTs are allowed -- with everything else stripped out (and logged as anomalous) by the bastion-proxy.
• joe_the_user 16y ago
  If this kind of filtering was possible for a browser to do after receiving the input, it would be possible for the server to do to it's output before it sent that output to the browser. IF this signing this was a solution, a given server could immediately solve its problem by doing this - at the cost of some processing time. And if a given server wasn't interested in solving the problem now, they might not implement the solution even if it was implemented in some portion of the browsers out there - indeed, why would any server bother to implement a security protocol which didn't nail every exit (there would always be browsers which didn't follow the new signing protocol. Youtube could patch its problem immediately or wait a decade or two for your solution to happen...).
• Daniel_Newby 16y ago
  Your proposal only closes a few possible holes. This is worse than nothing, because it creates a false sense of security. The reason is that JavaScript code trusts the DOM in many and varied ways, and can thereby be tricked into doing unexpected things by plain HTML code. Consider a page using a calendar.js plug-in, and a user-provided element '<div class="calendar" month="13">...</div>'. This could easily result in JavaScript code being configured with hostile parameters and event handlers being bound to hostile elements. The only way to handle complex user-provided input is to start with a blank slate, parse the input completely, and only create output that is proven safe.