Re: New URL spoofing bug in Microsoft Internet Explorer

From: Martin Maher (gentoo_at_PENGUINDREAMS.US)
Date: 10/31/04

  • Next message: "p h i s h i n g p h o r p h u n p h o r p h u q u e s a k e"
    Date:         Sun, 31 Oct 2004 13:17:03 -0700

    What Marjolein says is true about the errors with the code but I
    think something has been missed in the situational application of the
    example. Specifically, since an anchor can *not* contain a block
    level element, then the second anchor tag *should* fail as well. Why
    you ask - because a closing tag for a block level element cuts off
    what follows just as surely as an opening tag for a block level

    I believe Russ Thomas' tree is a correct metaphor for this situation
    but with an incorrect outcome. Just as surely as the branch begun by
    the <table> element gives an "end of stream" for the first anchor
    tag, the explicit *ending* of a branch should yield an "end of
    stream" for the second anchor tag.

    IMHO, *neither* tag should work according to the rules and *any*
    attempts to *interpret* an intended outcome will yield an erroneous

    Additionally, long gone should be the days when parsers (web
    browsers) should be granting leniency to incorrect HTML vis a vis
    *predicting* the intention of the author. This sort of flexibility
    was originally allowed because this code was being written by hand by
    scientists whose simple intention was to provide a visual tweak to
    their data as it was shared by the then nacent WWW.

    IM(second)HO, current browsers should strictly parse the HTML and
    display it on the page. This would at the very least allow for the
    determination of *bug* or *not bug* when we see issues such as this.
    Now with leniency allowed on this level, we end up in dicussions of
    *best method* for interpreting an *error* - intentional in nature or
    not. The only *design decision* a browser writer should have is what
    standards level to parse unmarked HTML to (i.e., HTMLv2, HTMLv3,

    And before anyone goes *there*, the excuse that this imperils
    attempts to hand-write HTML (which is how I do all mine, btw) because
    of the possibility of over-looked tags, copying errors in long
    documents, etc. - welcome to writing code. And also to mitigate this
    possible handicap, there are a slew of free and very low cost strict
    code parsing error checking products on the market.

    With all of the current concerns about security, I don't understand
    how it can be acceptable behavior to allow a program with as wide a
    data-catching net as a web browser to *guess* with information that
    is inbound to our networks. This makes everyone who accepts this
    *feature* complicit in the security problems on their own networks.


    Martin Maher

    >At 22:19 2004-10-29, you wrote:
    >>In isolation, the google href may appear to be the most well-formed, but
    >>since HTML shouldn't be treated as isolated data islands, but instead as a
    >>sequence from beginning to end, the fact that XP SP2 renders
    >> as the link is just wrong (even if it does mean the
    >>spoofing attempt fails.)
    >Excuse me, but I beg to differ.
    >The HTML standards have some rules and guidelines for how to render valid
    >code - they do NOT have guidelines for how to render invalid code. And the
    >example code given clearly is invalid. But there is no "right" or "wrong"
    >with what a browser does with that.
    >When a browser (any user agent) encounters invalid code, it can do anything
    >it "thinks" is appropriate with it (one reason why so many browsers are so
    >bloated: they do a lot of guesswork). There are no rules.
    >There are, in fact two errors with the code:
    >- an anchor cannot contain a block (and a table is a block)
    >- anchors cannot be nested
    >What "should" a browser do with these?
    >- If one takes the first rule, then it seems "natural" for a browser that
    >does even a little bit of validation in its attempts to guess to discard
    >the first opening a tag upon encountering the opening table tag going on a
    >general rule of thumb that an opening block-level tag ends whatever connot
    >contain a block. (This is why a new opening p tag starts a new paragraph
    >even if it isn't preceded by a closing p tag.)
    >- If one takes the second rule - what to do? what to do? Since anchors
    >cannot be nested, discarding the first opening anchor tag OR ignoring the
    >second opening tag would seem equally sensible.

    NTBugtraq Editor's Note:
    Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the message and place it in your TO: field.

  • Next message: "p h i s h i n g p h o r p h u n p h o r p h u q u e s a k e"