2 ms·

> I think this is a fair bit different than being lenient on HTML interpretation. It's not. There are two areas where the leniency was a problem here. Firstl

• dpark 10y ago
  > It's not. There are two areas where the leniency was a problem here. Firstly, the leniency in rendering one media type as a completely different media type because the browser heuristic thought it was being lenient. Secondly, the leniency in parsing HTML out of an image file – you can't do that with valid HTML. I think you can argue the first is a problem. You have an example demonstrating as much. Arguing that the second is a problem is much harder. Lenient HTML acceptance been hugely advantageous to the adoption of the web. There may have been some issues from this, but it's valuable enough that the effort to "fix" it was abandoned and the W3C and WHATWG returned to codifying what leniency should look like. > I've literally just given three specific examples of it causing security vulnerabilities. Well, at least one example. Coercing a file served as an image to HTML isn't an issue of accepting malformed HTML, nor would I agree that the JS example is a problem with leniency. > No, it was intentional. It was specifically Unicode characters that looked like less than and greater than signs, but weren't. Okay, I reread your last comment. I initially thought you were saying that Netscape was treating '&lt' as '<'. So Netscape decided to treat some random unicode chars that happen to look kind of like the less-than symbol (left angle bracket: ⟨, maybe?) as if they're the same as the less-than symbol? This seems amazingly short-sighted and pointless. How was this issue not seen, and was this even solving a problem for someone? > Somebody noticed that href="java\nscript:…" wasn't being parsed as JavaScript, and it was causing some malformed pages to fail to work properly. Rather than let it fail, they tried to fix it by stripping out the whitespace, and caused a security vulnerability. So the issue here is incompetent input sanitization. I don't think the browsers being lenient here is the issue. > If these three examples aren't enough, take a look at OWASP's XSS filter evasion cheat sheet. There's plenty of examples in there of lenient parsing causing security problems: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She... A few of these are interesting in the context of browsers being lenient. e.g. This one requires lenience as well as poor filtering: <IMG """><SCRIPT>alert("XSS")</SCRIPT>"> Most of these are just examples of incompetence in filtering, though, and a great example of why you 1) should not roll your own XSS filter if you can avoid it, and 2) why you should aggressively filter everything not explicitly acceptable instead of trying to filter out problematic text.
  • JimDabell 10y ago
    > Arguing that the second is a problem is much harder. Lenient HTML acceptance been hugely advantageous to the adoption of the web. Wait, that's a completely different point. The argument here is that it caused a security vulnerability, and it did. If the lenient HTML parser didn't try to salvage HTML out of what is most certainly not valid HTML, then it wouldn't be a security vulnerability. > This seems amazingly short-sighted and pointless. How was this issue not seen, and was this even solving a problem for someone? You could ask the same of most cases of lenient HTML parsing. It's amazing the lengths browser vendors have gone to to turn junk into something they can render. > So the issue here is incompetent input sanitisation. No, it isn't. That code should not execute JavaScript. The real issue is that sanitising code is an extremely error-prone endeavour because of browser leniency – because you don't just have to sanitise dangerous code, you also have to sanitise code that should be safe, but is actually dangerous because some browser somewhere is really keen to automatically adjust safe code into potentially dangerous code. Take the Netscape less than sign handling. No sane developer would think to "sanitise" what is supposed to be a completely harmless Unicode character. It should make it through any whitelist you would put together. Even extremely thorough sanitisation routines that have been worked on for years would miss that. It became dangerous through an undocumented, crazy workaround some idiot at Netscape thought of because he wanted to be lenient and parse what must have been a very broken set of HTML documents. This is not a problem with incompetent sanitisation. It's a problem with leniency.
    • dpark 10y ago
      You have some compelling examples of problems from leniency. I think in some cases the issues are definitely magnified by other poor designs (bad escaping/filtering) but you've demonstrated that well-intentioned leniency can encourage and even directly cause bugs. Thanks for providing actual, concrete examples.