Opened 12 years ago

Last modified 11 years ago

#10773 closed defect

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

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

Description (last modified by bill)

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 (3)

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.

comment:2 Changed 12 years ago by bix

I did not see any area where security issues should be released, that's why I made the decision to release it here. I would recommend putting some verbiage in your FAQ on who to message when the security community has vulnerabilities to submit.

I did some google searching and found a bunch of sites that had these files in their webroot.

I have no problem deleting the details here until you've released a patch and then we can make it public.

Let me know what you think.

comment:3 Changed 12 years ago by bill

Description: modified (diff)
Owner: changed from anonymous to bill
Status: newassigned

I'll check in a fix. Not sure which "encoding function" you are talking about but AFAICT we can just filter out special characters as they shouldn't be occurring in the strings, using replace(). (I did so and the tests all still pass.)

Note: See TracTickets for help on using tickets.