will reproduce on a newer build ... rebuilding Firebird now...
I tested Firebird, IE, Opera, and Netscape 4 on that page. Firebird is the only one that shows bold text. Opera spins and never finishes loading the page, probably because the SCRIPT tag is never closed. The corresponding view-source problem is bug 70918.
*** This bug has been marked as a duplicate of 213383 ***
No bug in Mozilla. Bug in the form validation/correction code.
It's not the same bug. I agree with your interpretation of the other bugs, but the problem exists in _where_ you interpret the '>', not _whether_ you interpret the '>'. So far there has been no discussion on where you interpret the '>'. If you fix it by inserting the '>' before the first ' ', you'll end up with perfectly well-nested code for further parsing, but you won't be interpreting the attributes, downloading code, and executing it. Of course, I suggested above you insert '>' before / (href|src|on[a-z]+)=|</i instead of just / / or /</, to be more lenient to web developers. I don't challenge that this bug only manifests in improper code translation/validation situations, either, but, since it is common that this mistake is made, I think it's necessary to be pre-emptively defensive and take the position that errors such as this mean that it's not trusted to execute arbitrary code. BTW, I did rebuild a newer version and duplicated it on a Nov 22 CVS HEAD build.
Reopening based on comment 5. I don't understand comment 5, but I guess a parser person should look at it.
Actually, as I understand it, proper parsing of SGML/HTML _requires_ that we behave this way. That is, the '<' of the next tag is a valid way to close out the markup of a previous tag... choess, is that the case?
Full-disclosure thread about this bug: http://lists.netsys.com/pipermail/full-disclosure/2004-July/023942.html
Note http://lists.netsys.com/pipermail/full-disclosure/2004-July/023995.html Also note that changing this behavior is likely to be a very difficult and dangerous HTMLParser change; there _are_ cases when IE will do SHORTTAG properly here (what exact cases? I don't know; that's why it's dangerous -- it's very easy to break a lot of markup that's out there. But I recall bugs on it). So just breaking this HTML feature (_required_ by the spec) altogether is not really feasible. 'm not sure anyone who understands the parser well enough to do some sort of evil hack for just the script case can actually be found...
Actually if you study this you'll find that both IE and Opera do the same as Mozilla, that is, they parse the <script> tag and put it into the DOM and so forth. I examined IE in particular, and found that it even fetches the JS file pointed to by the src attribute. What I don't understand is why IE then ignores that file -- it doesn't seem to do anything with it.
Aha. The trick is to give IE a "</script" sequence, that's when it executes the script. So this "security problem" can be reproduced in IE: http://www.hixie.ch/tests/adhoc/html/parsing/compat/019.html I think this is INVALID. Just like the second full-disclosure post above says, the pages that are susceptible to this are faulty. They should be allowing safe stuff through, not blocking unsafe stuff. (There are literally dozens of ways of executing script in IE.)
The pattern is that it will execute the script as soon as it sees the "</script" tag. (Note the lack of ">", which is relevant to this bug, and is why I think we should call this invalid.)
(In reply to comment #14) > See also > http://www.zapthedingbat.com/security/scriptinjection/ that's totally unrelated
This is going to be fixed by bug 305873. I'm marking this as WONTFIX since the summary seems to suggest that we shouldn't do this parsing for other tags, which we won't change. Note that IE actually requires a > (so the document: |<script>alert("hi")</script| doesn't execute a script).