565689 - [HTML5] wsecu.org - WSECU bank page contains "</script>" inside <script> element, breaks with HTML5 parser

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Matt Brubeck (:mbrubeck)]

Attachment: minimal test case

After submitting the login form at https://www.wsecu.org/ the response page includes this invalid markup (note the "</script>" contained in a JavaScript string literal):

<script>
<!--
  document.write("<" + "script language='javascript' src='/cas_login/sessionclose.asp?js=1&rnd=" + new Date().getTime() + "'></script>");
-->
</script>

This works as intended without the HTML5 parser (in Firefox 3.6, or on trunk with html5.enable = false), but with the HTML5 parser it fails.  As I understand it this is the desired behavior of the parser, so I am filing this as a tech evangelism bug.

Please don't submit a bunch of fake logins to my bank - use the attached test case if you want to see the results for yourself.

Comment 1

[Matt Brubeck (:mbrubeck)]

Moving to HTML5 parser to verify that it is an intended change.  If it is not a parser bug, please reassign back to Tech Evangelism.

Comment 2

[Matt Brubeck (:mbrubeck)]

I notified WSECU of this problem, and am told that my report was forwarded to their "E-Services team".

Comment 3

[Henri Sivonen (:hsivonen)]

This is an intentional change. Prior to the HTML5 parsing algorithm, browsers backtracked and reparsed when seeing an EOF inside a script to deal with </script> inside an inline script. This means that prior to HTML5, an accidental or maliciously forced premature end of file could change the executability properties of pieces of an HTML file.

The current magic in the spec was carefully designed and researched to permit forward-only parsing in a maximally Web-compatible way. The solution in the spec was known to break a handful of pages among lots and lots of pages listed by dmoz, but the breakage was deemed negligible.

This is probably the highest-risk change in the HTML5 parsing algorithm, and this is the first report of it breaking an "important" contemporary site. Considering that keeping the forward-only tokenization behavior is highly desirable, in the absence of evidence of more important breakage, I'm treating this as an evang issue realizing that further evidence may force us to revisit this part of the spec. But let's try to get away with forward-only parsing!

FWIW, on the Web scale, it's very rare to have an inline script that
 1) wraps the script in <!-- ... -->
AND
 2) makes an effort to mask the string "<script" by splitting it
AND
 3) does not make similar effort to mask the string "</script>"

The easiest and the most reliable (in both legacy parsers and in HTML5-compliant parsers) way to avoid problems with markup inside string literals inside inline scripts is to escape < as \u003C. It's safe to do this substitution unconditionally for all occurrences of < in string literals but doing it for "<!--" and "</script>" is important. When this safe method is applied, the less reliable <!-- ... --> tradition is unnecessary. (I would strongly discourage authors from trying to come up with cleverer tricks by reading the magic in the parsing algorithm.)

Thus, the safe way to write the script from the bug descriptions is:
<script>
  document.write("\u003Cscript language='javascript'
src='/cas_login/sessionclose.asp?js=1&rnd=" + new Date().getTime() +
"'>\u003C/script>");
</script>

Comment 4

[Chris Lawson (gone)]

Matt, I'm assigning this to you for now since a) you're a customer and b) you're already in dialog with them about it. Please keep us posted and follow up with them if you haven't heard anything (or seen a fix) in a month or so.

cl

Comment 5

[Matt Brubeck (:mbrubeck)]

This issue is not yet fixed.  I sent another email to WSECU's customer support.

Comment 6

[Matt Brubeck (:mbrubeck)]

This issue has been fixed by WSECU.