7 ms·

A testament to one of the worst decisions in computing history - not to fail displaying a web page with an error message in case it is not a valid HTML document

• rimantas 10y ago
  Or one of the best. Switch wen browsers to strict processong and you will hardly find working web page.
  • ygjb 10y ago
    Yeah, imagine if processors gave best effort to processing binaries... what could possibly go wrong :/ The decision to allow this was made early and the liberal accept/strict transmit paradigm has in general made the web a mess. On the plus side, the consistent failure of browser vendors to apply strict controls to input means that as an application security person I will probably never be out of work :D Even though this pattern of behavior is starting to change, legacy support means that I will still be dealing with these issues well into my retirement!
    • dpark 10y ago
      > as an application security person I will probably never be out of work How many security flaws are the result of malformed HTML?
      • Chernobog 10y ago
        Malformed HTML may escape sanitization on input in a vulnerable web app, and still render on the victim's browser because their browser wants to be helpful. (Yes, the output should have been escaped, but that is sadly not always the case)
        • dpark 10y ago
          I don't see how this has anything to do with malformed HTML or lenient rendering rules. In the scenario you're describing, well-formed but malicious HTML could also escape sanitization.
      • JimDabell 10y ago
        Malformed HTML? None. Browsers attempting to be lenient in what they accept? Loads. To take this article as an example, according to the HTTP specification, the `Content-Type` header is supposed to have the final say in what media type is being served. Internet Explorer decided it would be better to use heuristics. I think the idea was that if a web host was misconfigured, rather than have the web developer fix their bug, it would try to guess its way out of the error. Which kinda worked. The problem was, it opened it up to abuse. If you had a web host that allowed untrusted people to upload images (e.g. profile photos), you could construct an image that tricked Internet Explorer into thinking that it was an HTML document, even if the server explicitly told clients that it was an image. The main difference between images and HTML, of course, is that HTML can contain JavaScript, which would now execute in the security context of your web page. So all of these web hosts, thinking they were only giving people the ability to upload images, were now letting people execute JavaScript on their domain – simply because Internet Explorer tried to be lenient. The workaround ended up being forcing downloads with `Content-Disposition` headers instead of displaying inline. That's why, for example, visiting the URL of an image on Blogger directly triggers a download instead of showing the image. Other examples that spring to mind: Netscape interpreting certain Unicode characters as less than signs. People were correctly escaping `<` as `<` but the Unicode characters slipped through and caused XSS vulnerabilities in that browser. Browsers ignoring newlines in pseudo-protocols. Want to strip `href="javascript:…"` out of comments? No problem… except some browsers also executed JavaScript when an attacker placed a newline anywhere within the `javascript` token. Being lenient in what you accept has caused security vulnerabilities over and over again and there's no reason to think that it will stop now.
        • dpark 10y ago
          > To take this article as an example, according to the HTTP specification, the `Content-Type` header is supposed to have the final say in what media type is being served. Internet Explorer decided it would be better to use heuristics. I think the idea was that if a web host was misconfigured, rather than have the web developer fix their bug, it would try to guess its way out of the error. Which kinda worked. The problem was, it opened it up to abuse. If you had a web host that allowed untrusted people to upload images (e.g. profile photos), you could construct an image that tricked Internet Explorer into thinking that it was an HTML document, even if the server explicitly told clients that it was an image. The main difference between images and HTML, of course, is that HTML can contain JavaScript, which would now execute in the security context of your web page. So all of these web hosts, thinking they were only giving people the ability to upload images, were now letting people execute JavaScript on their domain – simply because Internet Explorer tried to be lenient. This is an interesting example, though I think this is a fair bit different than being lenient on HTML interpretation. The topic was strict HTML. Accepting malformed HTML doesn't seem to pose much of a problem. Blindly executing a non-executable file seems like a much different problem. > Netscape interpreting certain Unicode characters as less than signs. People were correctly escaping `<` as `<` but the Unicode characters slipped through and caused XSS vulnerabilities in that browser. This doesn't sound like being lenient. This just sounds like a bug. > Browsers ignoring newlines in pseudo-protocols. Want to strip `href="javascript:…"` out of comments? No problem… except some browsers also executed JavaScript when an attacker placed a newline anywhere within the `javascript` token. Huh? I don't understand the scenario being described here. It again sounds like a bug rather than lenient acceptance of data, though.
  • danbruc 10y ago
    Which are the faults of the authors. No one expects malformed source code to compile, a video with corrupted headers to play properly or a binary containing invalid instructions not to crash. This decision allowed people to get away with broken web pages instead of forcing them to fix their mistakes.
    • eyelidlessness 10y ago
      It's a better web environment than it was years ago, but there was a time that even simple layouts required invalid code to display similarly across the browsers of the time.
    • dwaltrip 10y ago
      The web would not have been as successful if it wasn't for this leniency. Full correctness is only worthwhile if both attaining it does not excessively harm other goals and the cost of not attaining it is severe enough. The cost of a malformatted HTML document rendering despite the errors is not that severe compared to the benefits it provides, as we have seen.
  • nolok 10y ago
    Well of course if correctness is not a requirement then it's not being paid attention to. That doesn't in any way indicate that it was a good decision not to require it in the first place.
    • notahacker 10y ago
      If it had been made as difficult as possible for enthusiasts learning a markup language to get what was essentially text document to actually display anything, it's probably not too much of an exaggeration to say the World Wide Web wouldn't have existed in its current form. It's not as if many of the web's security holes are related to whether a page displays valid HTML markup or not.
      • danbruc 10y ago
        I don't think the assumption is justified that enforcing well-formed HTML documents would have been a significant barrier. To me it actually seems easier to have a few simple and strictly enforced rules than having a more or less random assortment of exception to save a handful of key strokes.
        • notahacker 10y ago
          The failure of XHTML Strict suggests otherwise. Ultimately it's less about saving keystrokes and more about amateur enthusiasts having the opportunity to start with the browser rendering their unformatted document rather than an "Error at line 1" warning, and changes they introduce being considerably less likely to break the entire page
          • sievebrain 10y ago
            XHTML Strict only solved one set of leniencies in the web platform, which were also the least important kinds. Malformed HTML makes writing browsers complicated but doesn't generally seem to cause security issues or other visible, obvious, must-fix-now problems. The real security due to leniency problems in the web platform revolve around the handling of data and how JavaScript works, which were not addressed by XHTML. In that sense it's not surprising it went nowhere.
• arcatek 10y ago
  I kinda agree, but one has to concede that XHTML has failed for a reason.
  • oldmanjay 10y ago
    XHTML failed because doing the old, broken, tag-soupy mess still worked exactly as well from the user perspective. You just can't get people to work harder for invisible benefits. In a sense, it's a reason, but it doesn't mean that tag soup is a good thing. I often wonder how different the internet would be if Postel's prescription never gained traction and fail-fast behavior were the norm instead.
    • throwanem 10y ago
      It would probably be a lot smaller!
    • acdha 10y ago
      Also because all of the tooling was terrible and extensibility was non-existent. It's easy to imagine a world where XHTML worked out better because the browsers provided clear, informative errors rather than a blank page, someone at the W3C cared enough to have a usable validator which produced helpful warnings and errors, and attention was paid to the less friendly bits of the XML ecosystem[1]. Instead, it felt like we had a bunch of people who though that big lofty standards were so obviously correct that everyone else would take care of those boring implementation details, and 99.9999% of web developers correctly realized that there was very little measurable downside to sticking with something which was known to work. 1. Simple examples: namespacing is a good idea but it leads to gratuitous toil in most tools – e.g. a valid XML document which has <foo> should just work if you write a selector for /foo, as present in the document, rather than requiring you to do kludgey things like have to lard up every parser registering the same namespaces which are also declared in the document and writing fully-qualified selectors like /mychosenprefix:foo or /{http://example.org/fooschema/1.0}foo http://example.org/fooschema/1.0}foo for every tag, every time. Similarly, getting XPath 2.0 support to actually ship in enough tools to be usable would have made one of the better selling points for using XML actually exist as far as the average working programmer is concerned.
• TazeTSchnitzel 10y ago
  Being flexible about what markup is accepted has meant the web could gain new features and gracefully degrade, and has made it more fault-tolerant. It's not at all a failing. Compare that to JavaScript, which will happily fail if you use new syntax or a missing function, and thus web pages which rely on JS often show up as just a full screen of white when something goes wrong, which it frequently does. That's not to say JS should be as flexible as HTML is here, but it provides an interesting contrast.
  • danbruc 10y ago
    A parser could always just ignore tags it does not recognize, no need to try to make sense of any random collection of tags.
  • witty_username 10y ago
    > Compare that to JavaScript, which will happily fail if you use new syntax or a missing function, and thus web pages which rely on JS often show up as just a full screen of white when something goes wrong, which it frequently does. Isn't that more due to failure to handle exceptions and display errors to users?
    • cbsmith 10y ago
      > Isn't that more due to failure to handle exceptions and display errors to users? You could describe it that way.... or you could describe it as failing to have reasonable default logic for handling faults & gracefully degrade.
    • TazeTSchnitzel 10y ago
      Silent failure or not, the page still doesn't work.
  • Houshalter 10y ago
    There's nothing wrong with some tolerance, like ignoring tags that it doesn't know. But if the syntax is wrong, it shouldn't try to fix it or guess what the user meant, just display an error. Accepting invalid syntax means all HTML parsing becomes vastly more complicated. Which creates room for bugs, exploits, and unexpected situations like OP's post.
• iaw 10y ago
  How would you have prevented huge schisms during the IE push? In a world where invalid HTML documents aren't rendered at all we could have had the evolution of the format dictated by Microsoft because of their market position.
• marcuskaz 10y ago
  This actually used to happen, to some degree. No error, but you would get a blank page in Netscape if you failed to close a TABLE tag. They started making browsers more lenient since there was so much poor malformed HTML being produced
• castell 10y ago
  So you are one from the XHTML2 camp then? Good we got HTML5 and good that the weird years of transition to XHTML 1 and unclear vision with XHTML2 and ECMAScript for XML (E4X) are long gone.