Page 1

DOMinator Pro User Manual: Trial Version

Date, version:

01-10-2012, 1.0


Index 1 1.1 1.2 1.3

LICENSE...................................................................................................... 1 DOMinator Pro license agreement ......................................................................... 1 DOMinator Pro Terms & Conditions of Purchase ............................................... 1 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: Public

Version: 1.0

Data: 01-10-2012 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: 

1.3

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

Revision

Document version is 1.0 and was written in October 2012.

Classification: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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

Classification: Public

Version: 1.0

Code Beautifier

Date: 01-10-2012 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 usersupplied 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] 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] 2

Classification: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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 4.1.1

From URL to DOM-XSS 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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 4.2.1

From Text-Box to DOM-XSS 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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: Public

Version: 1.0

Date: 01-10-2012 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 4.3.1

Redirection to Javascript: Protocol 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: Public

Version: 1.0

Date: 01-10-2012 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: 

4.3.3

http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-andsomething.html

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: Public

Version: 1.0

Date: 01-10-2012 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: ď&#x201A;ˇ

var rr = location.search.substring(1); if(rr)window.location.pathname=decodeURIComponent(rr);

Classification: Public

Version: 1.0

Date: 01-10-2012 Page 22

<i>fdgfdgd  

<script>alert(0)</script>