Opened 12 years ago

Last modified 11 years ago

#10773 closed defect

Multiple DOM-Based XSS in Dojo Toolkit SDK — at Version 1

Reported by: bix Owned by: anonymous
Priority: blocker Milestone: 1.4.2
Component: General Version: 1.4.0
Keywords: DOM XSS Cc:
Blocked By: Blocking:

Description (last modified by James Burke)


Multiple DOM-Based XSS in Dojo Toolkit SDK Adam Bixby - Gotham Digital Science

Affected Software: Dojo Toolkit SDK <= Build 1.4.1rc1

Browser used for testing: IE8 (8.0.7600.16385)

Severity: High


  1. Summary


The Dojo Toolkit is an open source modular JavaScript? library/toolkit designed to ease the rapid development of cross platform, JavaScript/Ajax? based applications and web sites. Multiple instances of DOM-based Cross Site Scripting (XSS) vulnerabilities were found in the _testCommon.js and runner.html files within the SDK. The XSS vulnerabilities appear to affect all websites that deploy any of the affected SDK files. These files are designed for testing, however a Google search identified numerous sites which have deployed these files along with the core framework components.

More information on DOM-based XSS can be found at


  1. Technical Details


File: dojo-release-1.4.1-src\dojo-release-1.4.1-src\dijit\tests\_testCommon.js 1) Data enters via "theme" URL parameter through the window.location.href property. Line 25: var str = window.location.href.substr(window.location.href.indexOf("?")+1).split(/#/);


2) The "theme" variable with user-controllable input is then passed into "themeCss" and "themeCssRtl" which is then passed to document.write(). Writing the un-validated data to HTML creates the XSS exposure. Line 54:


var themeCss = d.moduleUrl("dijit.themes",theme+"/"+theme+".css"); var themeCssRtl = d.moduleUrl("dijit.themes",theme+"/"+theme+"_rtl.css"); document.write('<link rel="stylesheet" type="text/css" href="'+themeCss+'">'); document.write('<link rel="stylesheet" type="text/css" href="'+themeCssRtl+'">');


File: dojo-release-1.4.1-src\dojo-release-1.4.1-src\util\doh\runner.html 1) Data enters via "dojoUrl" or "testUrl" URL parameters through the property. Line 40: var qstr =;


2) The "dojoUrl" and "testUrl" variables with user-controllable input are passed to document.write(). Writing the un-validated data to HTML creates the XSS exposure. Line 64: document.write("<scr"+"ipt type='text/javascript' djConfig='isDebug: true' src='"+dojoUrl+"'></scr"+"ipt>");


document.write("<scr"+"ipt type='text/javascript' src='"+testUrl+".js'></scr"+"ipt>");


  1. Proof-of-Concept Exploit


This vulnerability can be exploited against websites that have deployed any of the 145 SDK files which reference _testCommon.js.

Reproduction Request:"/><script>alert(/xss/)</script>

(Note: test_Button.html is one of the SDK files that includes the _testCommon.js file)


This vulnerability can be exploited against any website that has deployed the runner.html file.

Reproduction Request:'/>foo</script><'"<script>alert(/xss/)</script>


  1. Recommendation


A JavaScript? encoding function should be wrapped around the user-controllable variables to ensure that malicious data is properly encoded before rendering in the browser.

Change History (1)

comment:1 Changed 12 years ago by James Burke

Description: modified (diff)
Milestone: tbd1.4.2

Thank you for the report. While we do not have a formal security policy set up, I believe normal security practice is to try to contact a team member in a private channel and allow us to work on the issue before making it public. Or to open the bug but not mention specifics until one of us can contact you privately.

The two sources of the vulnerabilities, testCommon.js and runner.html are test files. It is not expected that those files are deployed to production servers, although I can see how it might happen, and it is best to avoid the problems if we can, so we should fix the issues. I have marked this for the 1.4.2 release.

Note: See TracTickets for help on using tickets.