DOMinator Pro User Manual:

Trial Version

Date, version: 01-10-2012, 1.0

Index
1 LICENSE...................................................................................................... 1
1.1 DOMinator Pro license agreement ......................................................................... 1
1.2 DOMinator Pro Terms & Conditions of Purchase ............................................... 1
1.3 Revision ..................................................................................................................... 1

2 QUICK START ............................................................................................. 2

2.1 Setup and Activation ................................................................................................ 2
2.2 User Interface ........................................................................................................... 2
2.2.1 Main Panel ............................................................................................................. 3
2.2.2 Vulnerability Deck ................................................................................................. 4
2.2.3 Source Bar .............................................................................................................. 5

3 INTRODUCTION .......................................................................................... 6
3.1 What is a DOM based Cross Site Scripting ........................................................... 6
3.1.1 What are the security impacts for an application vulnerable to a DOMXSS? ....... 6
3.1.2 IDS, IPS, FW, Web App FW can identify a Dom XSS attack?............................. 6
3.1.3 IDS, IPS, FW, Web App FW can mitigate a Dom XSS vulnerability? ................. 7
3.1.4 Which is the best approach to identify a DOMXSS?............................................. 7
3.2 Introduction to DOMinator Pro Technology ........................................................ 9
3.2.1 Innovative Approach ............................................................................................ 10
3.2.2 Realtime Dynamic Data Tainting Technology .................................................... 10
3.2.3 Architecture .......................................................................................................... 11

4 USE CASES .............................................................................................. 13

4.1 From URL to DOM-XSS ....................................................................................... 13
4.1.1 Quality Team - Identify the Issue ........................................................................ 13
4.1.2 Tester Team - Exploiting the Issue ...................................................................... 14
4.1.3 Developers - Fixing and Remediation ................................................................. 15
4.2 From Text-Box to DOM-XSS ................................................................................ 16
4.2.1 Quality Team - Identify the Issue ........................................................................ 16
4.2.2 Tester Team - Exploiting the Issue ...................................................................... 17
4.2.3 Developers - Fixing and Remediation ................................................................. 19
4.3 Redirection to Javascript: Protocol ...................................................................... 20
4.3.1 Quality Team - Identify the Issue ........................................................................ 20
4.3.2 Tester Team - Exploiting the Issue ...................................................................... 21
4.3.3 Developers - Fixing and Remediation ................................................................. 21

Classification: Version: 1.0 Data: 01-10-2012

Public Page ii
1 License

1.1 DOMinator Pro license agreement

The Full License Agreement is available online at the following address:
 http://dominator.mindedsecurity.com/eula-pro.html
Minded Security DOMinator Pro software is licensed to single user at the conditions
detailed in “DominatorPro_License.pdf” document.

1.2 DOMinator Pro Terms & Conditions of Purchase

IMPORTANT NOTICE: PLEASE READ THESE TERMS & CONDITIONS AND THE LICENCE
AGREEMENT REFERRED TO HEREIN BEFORE ORDERING OR DOWNLOADING ANY
SOFTWARE FROM DOMINATOR.MINDEDSECURITY.COM SITE
These Terms & Conditions constitute the terms and conditions on which Minded Security
Srl are available in the document “DominatorPro_License.pdf” available for download in
the private area of DOMinator Pro website.
DOMinator Pro Terms and Conditions of purchase are available online at the following
address:
 http://dominatorpro.mindedsecurity.com/tc.html

DOMinator Pro License is available online at the following address:

 http://dominatorpro.mindedsecurity.com/license.html

1.3 Revision
Document version is 1.0 and was written in October 2012.

Classification: Version: 1.0 Date: 01-10-2012

Public Page 1
2 Quick Start
2.1 Setup and Activation
Detailed information about Setup and Activation process is available by downloading the
QuickStart Installation Guide.

2.2 User Interface

DOMinator Pro user interface was designed to improve accuracy and speed in detection
of DOMXss vulnerabilities.
The following image shows Mozilla Firefox Browser GUI integration with DOMinator Pro:

WEB BROWSER

DOMINATOR PRO

DOMinator Pro interface has 3 different parts, as it is possible to see in the following
image:
 Main Panel (Blue Contour)
 Vulnerability Deck (Red Contour)
 Source Bar (Green Contour)

Classification: Version: 1.0 Date: 01-10-2012

Public Page 2
 Main Panel

Vulnerability Deck

Source Bar

2.2.1 Main Panel

Main Panel lets users control fuzzing operations and disable on-the-fly computational
intensive operations such as Logging or Tracing.
1. LOG Button. This button activates or stops DOMinator Pro from recording alerts
and other tainted information.
2. Stack Trace Activator. Stack Trace is a powerful feature, visually accessible in the
Call Stack window that maps tainted functions forward to the dangerous sink
functions. By default this feature is enabled for High Risk Issues (Alerts) and
cannot be disabled. StackTrace Activator will enable stack trace for the Medium
and the Low Risk vulnerabilities.
3. Fuzzer Buttons. Fuzzer will force the submission of potentially expected
parameters (in the javascript code) that were not previously available in the
request. This action is possible because DOMinator Pro continuously inspects the
DOM for getters and setters.

LOG Button Fuzzer Start & Stop Buttons

StackTrace Activator

Classification: Version: 1.0 Date: 01-10-2012

Public Page 3
2.2.2 Vulnerability Deck
Vulnerability Deck is where discovered security vulnerabilities are reported. To discover
DOMxss or other kind of javascript issues on their websites users just have to use
DOMinator Pro with the Log Button enabled. Issues will be automatically displayed on
screen in this panel.
1. Issue Tab. This menu shows issues grouped by their exploitability ratio. Alerts are
vulnerability with the highest probability of being successfully exploited.
Warnings group includes vulnerability with a medium chance of being exploited,
Infos are issues that may not directly have security implications.
2. Knowledge Base. One of the advantages of DOMinator Pro, is the availability of a
comprehensive knowledge base. Developers, Testers or Quality Engineers will find
useful information about the reported issue, the connected risk and the
suggested remediation steps.
3. Source History. This tab gives the history of the tainted input strings. Strings are
expanded for better readability and to assist testers during vulnerability
exploitation. This feature permits also to check the correctness of the validation
functions adopted.
4. Call Stack. Call Stack is a direct integration with Firebug javascript code debugger.
Alerts are herein directly connected with the vulnerable line of code.

Issue Tabs

Call Stack

Source history

Knowledge Base

Important Note: all the features presented are extensively described in the Use Cases
section with code examples.

Classification: Version: 1.0 Date: 01-10-2012

Public Page 4
2.2.3 Source Bar
The source bar gives to the user the power of narrowing the analysis of security issues to
a smaller number of input categories. Inputs are categorized upon their source.

1. Source Buttons. These buttons controls activation of the tainting analysis for
particular sets of inputs. By default all sources are controlled except the cookie
source, because this particular input is usually not directly controllable. The
interested reader is invited to read DOMinator Pro Use Cases for more
information and examples.
2. Power Button. This button disables or enables DOMinator Pro extension. This
feature is useful to temporarily disable the tool.
3. Code Beautifier. This feature, if enabled, parses Javascript code and transforms it
into a format which is more easily readable. This feature is very useful during
code analysis in the Call Stack.

Source buttons:
C = Cookies
N = Name
R = Referrer
E = Input Elements
P = PostMessage
S = StoredStrings
D = DOM Strings

Power Button Code Beautifier

Classification: Version: 1.0 Date: 01-10-2012

Public Page 5
3 Introduction
3.1 What is a DOM based Cross Site Scripting
Cross Site Scripting (XSS) is a major security flaw present in Web applications today.
The XSS vulnerability in general occurs when an application generates a page with user-
supplied data without having them validated or done encoding. There are 2 kinds of XSS
generated by bad output encoding at the application side: Reflected XSS and Stored XSS.
Modern technologies for the Web such as Ajax allow a better interaction with the web
application by loading more and most of the code directly to customers using the
browser common technologies like JavaScript. This approach introduces a new kind of
vulnerabilities called DOM Based XSS (DOM XSS) and explained in the original paper by
Amit Klein in 20051.
While the Stored and Reflected XSS vulnerabilities are mainly due to the code that runs
the application, the DOM XSS arises from problems of the code (usually JavaScript) that
runs on the user's browser when interacting with the application.

3.1.1 What are the security impacts for an application

vulnerable to a DOMXSS?
XSS vulnerabilities are included in the list of the OWASP Top 10 risks for the web
applications2.
An attacker that discovers a DOMXSS vulnerability can exploit this issue to take complete
control of a user's browser interacting with the application, getting the authentication
cookie, credentials and any other confidential information as well as forcing a user to run
any application functionality without noticing it.
The impacts of security on the application that suffers from a XSS vulnerability depends
on the information managed and implemented features, it is however necessary to
emphasize the fact that only a single XSS vulnerability on a business application could
create significant harm to the company.

3.1.2 IDS, IPS, FW, Web App FW can identify a Dom XSS attack?
The OWASP Testing Guide3 collects all the possible tests you have to perform to a
running web application to verity that all the security controls are adequate. Looking at
the list of the tests to perform it is possible to notice that DOM Based XSS is the only
vulnerability running on the client browser, all the other vulnerabilities resides on the
server side as shown by the following picture.

1
DOM Based Cross Site Scripting or XSS of the Third Kind [http://www.webappsec.org/projects/articles/071105.html]
2
OWASP Top Ten Project [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project]
3
OWASP Testing Project [https://www.owasp.org/index.php/OWASP_Testing_Project]

Classification: Version: 1.0 Date: 01-10-2012

Public Page 6
 Fig. 1: Only DOM XSS is a vulnerability that can be exploited completely from the client
browser without interaction with the server-side components

This means that anyone can perform this analysis "without interaction" with the server
that is running the application itself. Unlike all other web application vulnerabilities, a
Dom XSS occurs without the owner of the application being aware of a possible intrusion.
That actually means a loss of control of the detection of security incidents and that’s
why it is really important to prevent this kind of attack.

3.1.3 IDS, IPS, FW, Web App FW can mitigate a Dom XSS
vulnerability?
The DOM XSS vulnerability resides inside the client code running on the user browser,
a Web Application Firewall and all the perimeter defense tools could do nothing to
mitigate this problem: it is not a possible solution.
The fundamental difference between the DOM and other types of XSS vulnerabilities
in web applications is that to remedy this issue you must edit and fix the JavaScript
code provided by the application.

3.1.4 Which is the best approach to identify a DOMXSS?

As noted the OWASP Top 102: "Web 2.0 technologies, such as AJAX, make XSS much
more difficult to detect via automated tools.".
Most of the problems of Dom XSS are very difficult to identify in a short time. As
shown by the project DomXSSWiki maintained by Stefano Di Paola4, the patterns of

4
DomXSSWiki [http://code.google.com/p/domxsswiki]

Classification: Version: 1.0 Date: 01-10-2012

Public Page 7
attacks are complex and require a thorough understanding of security issues to
perform an analysis of JavaScript code.
Stefano Di Paola at Ruxcon 2008 (Sydney, Australia - http://www.ruxcon.org.au ) and at
Swiss Cyber Storm 3 described a new methodology for analysis and identification of DOM
Based XSS issues5.
First you have to identify the sources (the input data that can be directly or indirectly
controlled by an attacker) and the sinks (potentially dangerous functions the can be
abused to take advantage of some kind of exploitation):
 Find the Sources using the following RegExp (all Regexp © by Mario Heiderich)):
/(location\s*[\[.])|([.\[]\s*["']?\s*(arguments|dialogArguments|innerHTML|write
(ln)?|open(Dialog)?|showModalDialog|cookie|URL|documentURI|baseURI|refer
rer|name|opener|parent|top|content|self|frames)\W)|(localStorage|sessionSt
orage|Database)/
 Find the Sinks using the following RegExp:
/((src|href|data|location|code|value|action)\s*["'\]]*\s*\+?\s*=)|((replace|assi
gn|navigate|getResponseHeader|open(Dialog)?|showModalDialog|eval|evaluat
e|execCommand|execScript|setTimeout|setInterval)\s*["'\]]*\s*\()/
Now you get the sources & sinks and finally you can follow the flow on code like in the
following picture:

Fig. 2: Example of a Javascript code to analyse

The main problems using this approach are that:

 Javascript is not that easy to analyse!
 Code can be Compressed

5
DOMXss Identification and exploitation
[http://dominator.googlecode.com/files/DOMXss_Identification_and_exploitation.pdf]

Classification: Version: 1.0 Date: 01-10-2012

Public Page 8
 (function (p,a,c,k,e,d){…..})()
 Code can be Obsfuscated
c=‘’,
eval(unescape("%u0540%u0556%u054C%u0519%u054E%u0550%u0557%u0518").spli
t('' ).map(function(a){ c+=String.fromCharCode((a.charCodeAt(0)^1337))}))
 Code can be simply sla.ckers.ed :
this.__parent__.[‘l’+0x6f+’c’+0x61+’tion’]

So it is necessary to automate the process to find this kind of vulnerability. The possible
solutions to find DOM XSS using a tool are the following:
 Static Analyser:
Pro: Very good at finding flows if well implemented. Very fast.
Contra: the problems of every Static Analyser KB, reflection, runtime evaluation, lot
of False Positives + False Negatives etc.
 Script Injection to wrap sources and Sinks:
Pro: use native interpreter so no problem with obfuscation/compression
Contra: Cannot follow the flow.
 Runtime Analysis with Dynamic Tainting:
Pro: Uses native interpreter so no problem with obfuscation/compression, can follow
the flow.
Contra: doesn’t look at alternative paths. Just propagates the taint flag. No tracking of
operations. (Mostly used for defense like on perl tainting or php)
 Minded Security solution DOMinator Pro:
DOMinator Pro is a tool for analysing and identifying DOM XSS; it is a modified
version of SpiderMonkey (JS Engine) to add Dynamic Tainting and perform Taint
propagation Tracing. Also is a modified version of Firefox to add taint propagation to
DOM Attributes and chrome methods.
DOMinator Pro performs a Realtime Dynamic Data Tainting (Rea.Dy. Data
Technology) that represents a completely innovative approach.
In the following paragraph we describe the DOMinator Pro technology and we explain
why this represents nowadays the state of the art in finding DOM XSS vulnerabilities in
your site.

3.2 Introduction to DOMinator Pro Technology

This part covers various aspects of DOMinator Pro technology to give to the technical
reader an overview of the different features that permit to discover Javascript
vulnerabilities with the highest rate of precision.

Classification: Version: 1.0 Date: 01-10-2012

Public Page 9
3.2.1 Innovative Approach
DOMinator permits to discover vulnerabilities on-the-fly during normal web site
browsing. To achieve this goal Minded Security Engineers modified the inner engine of
Firefox browser. This part of the tool has been released open source with Mozilla license
and is fully available to download on GitHub6 code repository.
DOMinator Pro has the following advanced capabilities:
1. Extensive Rule Base. Like static code analysers, software analysers capable of
inspecting the source code of applications for finding security flows, DOMinator
Pro has its own rule base that permits to dissect the code and alert about security
flaws in Javascript code.
2. Data Flow Aware. DOMinator Pro search for vulnerabilities during browsing, but
it’s not merely searching for dangerous function calls. DOMinator Pro is aware of
which dangerous function is called by controllable input, and only in that case it
displays an alert.
3. Validation Function Analysis. In addition to data tainting, DOMinator Pro can
analyse Validation functions. For example, if a controllable input is finally output
encoded (no matter if it was previously decoded), DOMinator Pro will understand
that it may be a false positive and automatically lowers the risk rating.
4. Knowledge Base. Knowledge base is available in the context of the discovered
security flaws and gives vulnerability overview, exploitability conditions and
remediation aids.

3.2.2 Realtime Dynamic Data Tainting Technology

Rea.Dy. Da.Ta. technology (RealTime Data Tainting) is a unique feature in DOMinator and
DOMinator Pro tools. This feature is partly similar to the Data Tainting and Flow Analysis
feature available in some commercial static analyser tools, with the difference of being
designed to be processed in realtime.
This realtime technology has the additional advantage of getting function calls directly
from the DOMinator taint engine, without the need of creating complex and imprecise
parsers. Additionally tainting is also executed and not emulated, giving a perfect data
flow.
Difference between Rea.Dy. Da.Ta. (in DOMinator tool) and a common Data Flow engine:

6
DOMinator [https://github.com/wisec/DOMinator]

Classification: Version: 1.0 Date: 01-10-2012

Public Page 10
As shown in the above figure the main difference between the Data Flow graph created
by DOMinator, comparing it to the one created by commercial Static Analysers is the
avoidance of a Custom Parser.
Custom Parser is not the best choice for Javascript code, because Javascript tends to be
compressed and obfuscated. This common property makes it very difficult to be
interpreted by custom components. Differently, DOMinator Pro uses the Native
Javascript engine to create the dataflow. This assures a perfect understanding of
compressed and obfuscated code: if the browser understands the code, DOMinator Pro
will understand it as well.
In addition the dataflow follows the actions of the user while these actions are
performed (e.g. clicking a button, visiting a page, etc.); this capability makes a lot easier
for a security officer to understand what triggers the security alert and where the
security issue is located.

3.2.3 Architecture
The tool is based on a modified version of the latest Firefox browser, for supporting Ajax
and HTML 5 specifications including ECMA scripting and several new standards.
In addition to this part of the engine, called Tainting Engine, the tool uses a proprietary
Firefox extension that is capable of interfacing itself with Firebug (Javascript debugger).
This proprietary extension is DOMinator Pro.
In the following picture you can see a schema of the Architecture:

Classification: Version: 1.0 Date: 01-10-2012

Public Page 11
As shown on the picture above, DOMinator Pro gets tainting information from the
DOMinator Core component (Taint Engine) and adds to it the capability offered by its
analysers.
Currently analysers available:
1. String Function Analyser. String manipulation functions are expanded in the
“Source History” for reported issues. The user can immediately see what the
javascript code does with the supplied tainted inputs (e.g. Concatenation,
Character matching and Replace etc.)
2. Getters and Setters Analyser. Getters and setters are analysed and parsed for
extracting expected parameters. This information is very useful for giving
additional power to the fuzzer.
3. Validation Function Analyser. A reported issue may be a false positive if it is
preemptively validated. This analyser tries to understand if the vulnerability may
be exploited.
4. Browser Emulator. Different browsers have a different attitude of being exploited.
Firefox location is always encoded, Chrome location can be full overwritten etc.
Different design patters have implications in exploitation strategy. To be more
effective, DOMinator Pro emulates the insecurity behaviors of different browsers,
to let the user test multiple flavors under just one browser (Firefox).

Classification: Version: 1.0 Date: 01-10-2012

Public Page 12
4 Use Cases
The following test cases show how to use DOMinator Pro tool in different contexts.
The user should use the tool with in mind his particular goal, which may depend on
different aspects:
 Technical Skills. Quality Teams, Security Testers and Developers may have very
different technical skills. In the following Use Cases we are trying to create a
training pattern for understanding and improving the technical approach in
Identify, Exploit and/or Fix the security vulnerabilities. The paths herein presented
for Identifying, Exploiting and Fixing the issue have an increasing level of difficulty.
 Scope. A different subset of activities can have a very different scope. For instance
a user that is not interested in exploiting a vulnerability can simply skip that
paragraph.
Please bear in mind that these are basic use cases for explanatory purposes. In the full
version of this document it is possible to find other, more complex, use cases which cover
other kinds of vulnerabilities.

4.1 From URL to DOM-XSS

4.1.1 Quality Team - Identify the Issue
The very first type of security issues that can be frequently found are DOM cross site
scripting that get their inputs from the URL.
Imagine that you are browsing the following website:
 http://www.vulnerablewebsite.com
Clicking on a button on the menu, you visit the following URL
 http://www.vulnerablewebsite.com/webpage.aspx?menuid=3

Suddenly looking at the main panel you see the following alerts:

Figure 1 Html-Injection Alert

From the previous screenshot the very interesting information is that you got an HTML
Injection (e.g. Cross Site Scripting) from the location.href (e.g. the URL).

Classification: Version: 1.0 Date: 01-10-2012

Public Page 13
Important Note: Sink describes where the vulnerability is and the Source is where the
controllable input comes from.

Our job is done: HTML injection vulnerability that is coming from a user supplied input
location.href (URL).
Now it’s important to communicate to the Security testers:
 the exact location of the issue:
http://www.vulnerablewebsite.com/webpage.aspx?menuid=3
 The steps needed for reproducing the alert (e.g. Browsing to the main menu,
clicking About tab)

Hint: Selenium and iMacros tools can help to automate the steps, by recording the
sequence of the actions.
For more information:
 https://addons.mozilla.org/en-US/firefox/addon/imacros-for-firefox/
 http://seleniumhq.org/

4.1.2 Tester Team - Exploiting the Issue

Next step is to check where this issue has been found. This is easy, looking at the source
history:
 the exact location of the issue:
http://www.vulnerablewebsite.com/webpage.aspx?menuid=3#injectedstring<>”’

Figure 2 From URL location to HTML injection in “Source History” tab

Source history is a simplified call stack that shows the content of controllable strings.
Location.href can be controlled and the value is showed up in light green, after this string
is concatenated with another string by left and by right.

As it is possible to see from the above picture, it’s also possible to check if there are
validator functions in place by injecting HTML patterns after the # (hash); in this case I

Classification: Version: 1.0 Date: 01-10-2012

Public Page 14
injected the pattern #injectedstring<>”’ after the vulnerable URL. Using the “Hash” sign is
important because anything coming after it will not be sent to the server.
It’s possible to see from the last line that #injectedstring<>"' is not encoded (typical
encoded string is in the form of: #injectedstring%3c%22%27).
By supplying now the correct exploit it is possible to turn the vulnerability into a reflected
DOM cross site scripting attack:
 Standard HTML Injection Payload: <img/src='x'/onerror='alert(1)'/>
 Full Exploit for Internet Explorer 7+:
http://www.vulnerablewebsite.com/webpage.aspx?menuid=3#xss"></iframe><i
mg/src="x"/onerror="alert(1)"/><"

Note: Url location is default urlencoded by firefox, and that’s why firefox is not affected
by this particular vulnerability. Chrome implements a DOMXSS filter that blocks this basic
attack.
The full exploit takes into consideration also that the original pattern was inside an
<iframe> tag attribute.

Figure 3 DomXSS Exploit in Internet Explorer

4.1.3 Developers - Fixing and Remediation

Given the full exploit:
 Full Exploit for Internet Explorer 7+:
http://www.vulnerablewebsite.com/webpage.aspx?menuid=3#xss"></iframe><i
mg/src="x"/onerror="alert(1)"/><"

Now developers should activate the Stacktrace box and the Javascript Pretty Printer Icon
( ) as shown in the pictures below:

Classification: Version: 1.0 Date: 01-10-2012

Public Page 15
 Figure 4 Enabling Stack Trace and JS Pretty Printer is important for Developers

Important Note: Thanks to DOMinator Pro Browser emulation feature we can mimic
different browser insecure behaviors. This permits to show developers the vulnerability
inside DOMinator Pro/Firefox, even if the previous exploit works only under Internet
Explorer.

Now for a developer it is time to open the “Call Stack”:

Figure 5 Line of code that contains the vulnerability

The Call Stack interactively shows where the vulnerability is with the correct line. It is
possible to see “document.location.href” is not escaped properly.
It’s very important to output encode the value before it is displayed.
Correct fixing at line 116:
 Use the “encodeURIComponent()” function.
 encodeURIComponent(document.location.href) If browser is Internet Explorer,
Chrome or Safari.

4.2 From Text-Box to DOM-XSS

4.2.1 Quality Team - Identify the Issue
In the previous example we showed how DOMinator Pro tool is able to automatically
intercept page content, understanding the logic behind it and to passively show security
issues.
Unfortunately not all user behaviors can be reproduced automatically and some
vulnerability needs a proper approach to let DOMinator to discover them.
One of these cases is JavaScript vulnerabilities inside the Search Suggestion Tooltips.

Classification: Version: 1.0 Date: 01-10-2012

Public Page 16
 Figure 6 Tootip Suggestion Area

Since Tooltip Suggestions are very often based on a remote web service (i.e. a cloud
dictionary service) DOMinator Pro takes a couple of seconds to analyse the page
behavior.
By this reason the user needs to inject some patterns inside it, wait a bit longer while
looking at the vulnerability tab if any alert appear.

Figure 7 HTML Injection from TextBox

As shown in the previous picture we suddenly found a couple of very interesting Alerts.
The “innerHTML” method is in fact very similar to the previous “Document.write”
method and leads to a HTML Injection vulnerability. In this case the source is a
“INPUTElement.value” that represent the TextBox control (where we inserted the
“question”).
Lesson learned
 Do not interact with elements too fast. A bunch of seconds are needed for a
complete javascript analysis.
 Describe correctly the passages needed to reproduce the Alert. E.g. Open
DOMinator, go to main page, Insert some text… Wait 2 seconds

4.2.2 Tester Team - Exploiting the Issue

Taking the previous instructions for reproducing the issue it’s now time for exploiting it.
Looking at the source history we can see exactly where the information inserted goes:

Classification: Version: 1.0 Date: 01-10-2012

Public Page 17
 Figure 8 Source history from the textbox to HTMl Injection

The information comes from the “INPUTElement.value” (Textbox) and flows into an
HTML String assigned to the “UL.innerHTML” property

Figure 9 As before, but injecting HTML special characters

As you can see from the figure, there are several REPLACE operations that represent a
sequence of validation steps. However these are quite ineffective since our special chars
<>’” remain in the final string and are not stripped away.
By supplying now the correct exploit it is possible to turn the vulnerability into a reflected
DOM cross site scripting attack:
 Standard HTML Injection Payload: <img/src=”x”/onerror=”alert(1)”/>

Classification: Version: 1.0 Date: 01-10-2012

Public Page 18
 Figure 10 DomXSS Exploit

As mentioned, because of the bad usage of input filters, our standard HTML injection
payload for DOMXss worked nicely.

Lesson Learned:
 DOMinator “Source History” displays REPLACE and ENCODING operations and
therefore it permits to check if they are good enough for defending the code from
attacks.
 Steps to reproduce the exploit issue may not be trivial; these steps and the
considerations attached should be properly explained to the developers for a
correct fix.
 Example of report to the developers:
o Browse to the main site, click in the search textbox,
o start writing the following payload: <img/src=”x”/onerror=”alert(1)” until
the popup appears.
o The problem is due to a bad usage of filters since dangerous characters are
not filtered.

4.2.3 Developers - Fixing and Remediation

After being able to reproduce the issue, it is needed to find the problem in the code.
Source History gives a view to exploit the issue, but the Call Stack could be much
different from it. That’s why it’s important to look directly at the code instead.
As before, open the Call Stack Tab after activating the Stack Trace and the JS Beautifier:

Figure 11 The vulnerable HTML assignment

Classification: Version: 1.0 Date: 01-10-2012

Public Page 19
For a correct fixing of this particular issue, we suggest to use Whitelists instead of
blacklists:
 Use an appropriate Whitelist e.g. permitting only Alphanumeric characters plus –
(minus) and _ (underscore)
 This can be done using the replace() method plus a Regular Expression
 Fix at Line 2638: this[b].innerHTML = a.replace(/[^A-Za-z-_0-9]/g, "")

4.3 Redirection to Javascript: Protocol

4.3.1 Quality Team - Identify the Issue
In the following example we find another kind of vulnerability that may lead to a
Javascript Injection attack (Cross Site Scripting). In this case the attack is based on the
fact that many websites redirect users to another location (domain).
The website we are analysing is always:
 http://www.vulnerablewebsite.com/webpage.aspx
It’s not assured that browsing to a website you will be able to automatically trigger the
alert without sending to the server the correct parameters.
DOMinator Pro intelligent fuzzer, tries to mimic the same values that the javascript code
is expecting.
To launch the fuzzer go to the url you want to test and press the “play” button:

Figure 12 DOMinator Pro intelligent fuzzer

By browsing a website and/or by using also the fuzzer you may step into DOMinator
interface showing the following alerts:

Figure 13 Url redirection can be controlled through the location

If the redirection is controllable, an attacker may redirect the user to a Javascript:alert(1)

location which executes a Javascript payload (alert(1) in this case) in the contest of the
previous http:// or https:// location.

Lesson learned:
 DOMXss can be triggered without injecting HTML into the browser DOM.

Classification: Version: 1.0 Date: 01-10-2012

Public Page 20
  The Fuzzer is a handy and powerful tool, because it helps in finding the alerts
 Remember to tell to the testers that for finding a particular vulnerability they
have to browse to a particular URL and then press the play button

4.3.2 Tester Team - Exploiting the Issue

After being able to reproduce the Alert, you should open the Source History:

Location.search

Location

Figure 14 URL Redirection Source History

As stated above anything that come after ? (Question Mark) is sent to the browser
location.
By supplying now the correct exploit it is possible to turn the vulnerability into a reflected
DOM cross site scripting attack:
 Standard URl Redirection Payload: javascript:alert(1)
 Full Exploit: http://www.vulnerablewebsite.com/webpage.aspx?
javascript:alert(1)

The interested reader may find useful the following real case example:
 http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-
something.html

4.3.3 Developers - Fixing and Remediation

The typically wrong code that generates this kind of vulnerabilities and we found also in
this case, is the following one:
 var rr = location.search.substring(1);
if(rr)window.location=decodeURIComponent(rr);

Why this construct is vulnerable? Because the window.location assignment will overwrite
the full URL including the protocol used. An attacker by manipulating the URL parameters
in this case can set a different and dangerous protocol such as javascript: for the current
location.

Classification: Version: 1.0 Date: 01-10-2012

Public Page 21
To fix this vulnerability, in case you just want to redirect the users to a page on the same
domain, use the .pathname property for the location.
Pathname is not absolute, but relative and does not permit to arbitrarily modify the
protocol used:
 var rr = location.search.substring(1);
if(rr)window.location.pathname=decodeURIComponent(rr);

Classification: Version: 1.0 Date: 01-10-2012

Public Page 22