Showing posts with label DOMinatorPro. Show all posts
Showing posts with label DOMinatorPro. Show all posts

Wednesday, February 4, 2015

Comparing DOM based XSS Identification Tools on a Real World Vulnerability

Due to the lack of literature about DOM Based XSS identification tools awareness, we decided to write a paper that took the actual tools that are stated to be able to identify DOM Based XSS and test their capabilities when dealing with a real world DOM XSS issue.

"..
Minded Security has been the first company to launch a commercial tool aimed to identify DOM Based XSS  with a runtime approach: DOMinatorPro.
In 2012, as a result of our research on DOM XSS, we released the tainting engine on github.com as an open source project and created a commercial version that let users easily identify several kind of JavaScript vulnerabilities with a pretty high rate of accuracy .

Since then, some tools, open source and commercial, have been developed and awareness on this very topic grew among application security experts.

The following paper will try to give an unbiased study supported by objective facts about precision and accuracy of existing tools that are stated to identify DOM Based XSS vulnerabilities.
..."




Pdf here
Every feedback is really welcome!



Monday, August 4, 2014

Linkedin.com fixes a High Risk Vulnerability inside its Javascript Code

Linkedin.com security team released a patch after receiving our DOMinatorPro Enterprise analysis report.

Update: The fix was actually faster than the fix notification. The fix was made in less than ten days.


DOMinatorPro Enterprise is very clever in finding exploitable JavaScript security issues on complex JavaScript web applications. You can find a PDF report that describes a new DOMXSS (https://www.owasp.org/index.php/DOM_Based_XSS) issue discovery in one of the major social media websites: Linkedin.com.


Linkedin.com DOMXSS Full PDF Report:


New improvements make DOMinatorPro Enterprise even more powerful!

DOMinatorPro Enterprise has new and improved features that make the discovery and exploitation of such complex issues very easy:
  • “Smart Fuzzer”. DOMinatorPro Enterprise fuzzer is smarter: it collects actionable parameters and fill those parameters with the values expected by the javascript source code itself.
  • Third Generation Exploitability Check. DOMinatorPro Enterprise not only follows strings manipulation functions, not only checks how many times encoding or decoding functions are called, it understands which meta-characters are allowed. This makes exploitability analysis one step further.

Linkedin.com is #9 in Alexa websites ranking and has more than 300 million users (http://blog.linkedin.com/2014/04/18/the-next-three-billion/) making it the world largest professional network.

Here at Minded Security it is not the first time that we find Javascript vulnerabilities in social network related javascript code on this blog to protect internet users. We already talked vulnerabilities affecting the following social network websites:

JavaScript security is very important, even more in portals where users store their personal data. Attackers can target those portals to find and exploit High-risk JavaScript vulnerabilities like DOMXSS vulnerabilities, to perform the following attacks:
  1. De-anonymize user identities. By abusing a DOMXSS attackers can instantly know the identity of their web visitors if the vulnerability is affecting a website like a social media portal.
  2. Private information stealing. Reading information from the page of the user page and sending those to the attacker (e.g. private messages)Account Takeover. Session hijacking, credential stealing or performing actions on the behalf of the user.
  3. Wormable Pandemic. These vulnerabilities let attackers to create JavaScript worms that could spread malicious content among millions of users.
DOMinatorPro Enterprise can find and analyze issues like one on almost any web portal, giving the technical insights you need to find and validate a plethora of JavaScript security issues.

Wednesday, June 18, 2014

Financial Cyber-Threat Briefing

“Planning for Attack-Resilient Web Applications”

The next 11th July 2014 in London Minded Security, the Software Security Company, will present an overview of the most common and latest attack vectors affecting online banking and other financial online services, strategies and methodologies for addressing growing risks in this domain and demonstrate some of latest untraceable exploits as well as solutions to stop them.

The agenda


14.30 to 15:00 Registration and welcome
15.00 to 16:15 Keynote Presentation
16:15 to 16:30 Networking Break 
16:30 to 17:15 Live Demos 
17:15 to 18.00 Networking Drinks Reception

Speakers and presentations

"Emerging Cyber-Threats Targeting Financial Institutions"
This presentation will share research carried out on the root causes of security incidents caused by attacks from emerging threats such as malware banking. The session will provide practical examples of instances of compromises causes by various threat agents and provide an in depth analysis of methods and attacks vectors employed against online banking applications. The scope of this analysis will be to analyse the threats, simulate attacks and identify flaws in application architecture that can be prioritised for remediation. To simulate the attack, modelling techniques such as the attack kill chain and attack trees will be shown. The goal of this session is to provide information security officer’s examples of processes, methodologies and risk frameworks that can be used to identify countermeasures to mitigate emerging threats.

Speaker: Marco Morana, SVP Technology Risks & Controls, Citi

"Overview of Online Banking Malware & Countermeasures"
This session will present how attackers currently identify and exploit web vulnerabilities on financial institution websites to stealing credentials. Giorgio will also demonstrate how compromised customer PC’s can compromise online transaction platforms an overview of the technology being used for prevention. Finally Giorgio will present a new technology “AMT Banking Malware Detector” that allows banks to identify users infected with malware before they become victims of fraud.

Speaker: Giorgio Fedon, COO, Minded Security & OWASP Lead.

"Preventing In-Browser Malicious Code Execution"
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. Certain vulnerabilities in JavaScript code cannot be tracked by standard IDS or perimeter security measures, which leads to a huge potential vulnerability, the code can be abused to steal data or bypass authentication mechanisms in web interfaces. This presentation will demonstrate vulnerabilities and also present Minded Security’s latest countermeasure DOMinatorPro.

Speaker: Stefano Di Paola. CTO, Minded Security & OWASP Project Lead

Info & Registration

For more information and registration, please visit the following web page:

Friday, October 18, 2013

DOMinatorPro with Martin Hall at London Tester Gathering Workshops 2013

Martin Hall will give a talk "Bug Hunting for Fun and Profit" at the London Tester Gathering Workshops 2013.

http://skillsmatter.com/event/agile-scrum/ltg-workshops

During his presentation Martin will show a demo of DOMinatorPRO Standard and you will have the chance to try our product.

Martin will be showing how you can have fun, gain fame and money finding issues in software and websites you use every day. He'll also be showing you some of the basic tips and techniques that will enable you to become a great "Bounty Hunter". 

More information here:
http://skillsmatter.com/podcast/agile-scrum/martin-hall

Martin Hall is a Senior SDET Lead at Microsoft (Skype Division)

Thank Martin for your support!

Thursday, November 8, 2012

DOMinatorPro Fuzzer finds a DOM XSS on Google.com

Introduction a.k.a. tl;dr


A quite simple DOM Based XSS was found on https://www.google.com/ context using DOMinatorPro.
What I think it's interesting here, is to show how DOMinatorPro works in this real world case.

In order to give a more detailed description, i recorded a video (HD) to show how DOMinatorPro can help in finding those particular kind of issues.




Some Details

DOMinatorPro is a runtime JavaScript DOM XSS analyzer, which means it can check for complex filters and help in finding debug and/or unreferenced parameters during JavaScript execution.

In order to do that, DOMinatorPro exposes a fuzzer button which fuzzes the URL query string and html input elements that have keyboard events attached to them as shown in the youtube video.
By using that feature I found that the code in
http://www.googleadservices.com/pagead/landing.js
uses unvalidated input to build the argument for two document.write call.

This javascript is used, among others, by:
http://www.google.com/toolbar/ie/index.html
and
https://www.google.com/toolbar/ie/index.html
which means that one more time a (almost) 3rd party script introduces a flaw in the context of an unaware domain.

Source Analysis

From http://www.googleadservices.com/pagead/landing.js (which has now been removed) the following lines do not escape user input:

Line 53:
    if (w.google_conversion_ad) {
      url = url + "&gad=" + w.google_conversion_ad;
    }
    if (w.google_conversion_key) {
      url = url + "&gkw=" + w.google_conversion_key;
    }
    if (w.google_conversion_mtc) {
      url = url + "&gmtc=" + w.google_conversion_mtc;
    }
    if (w.google_conversion_raw) {
      url = url + "&graw=" + w.google_conversion_raw;
    }
    if (w.google_conversion_domain) {
      url = url + "&dom=" + w.google_conversion_domain;
    }
   
And those values are taken by using :
function google_get_param(url, param) {
var i;
var val;
if ((i = url.indexOf("?" + param + "=")) > -1 ||
(i = url.indexOf("?" + param.toUpperCase() + "=")) > -1 ||
(i = url.indexOf("&" + param + "=")) > -1 ||
(i = url.indexOf("&" + param.toUpperCase() + "=")) > -1) {
val = url.substring(i + param.length + 2, url.length);
if ((i = val.indexOf("&")) > -1) {
val = val.substring(0, i);
}
}
return val;
}
...
google_conversion_ad = google_get_param(url, "gad");
if (window.google_conversion_ad) {
(google_conversion_key = google_get_param(url, "gkw")) ||
(google_conversion_key = google_get_param(url, "ovkey"));
google_conversion_mtc = google_get_param(url, "ovmtc");
google_conversion_raw = google_get_param(url, "ovraw");
}
}

After the previous code, the url variable is used on line 91:

document.write('' name="google_conversion_frame"' +
' width="' + width + '"' +
' height="' + height + '"' +
' src="' + url + '"' +
' frameborder="0"' +
' marginwidth="0"' +
' marginheight="0"' +
' vspace="0"' +
' hspace="0"' +
' allowtransparency="true"' +
' scrolling="no">');

and line 103:

document.write(''src="' + url + '&ifr' + 'ame=0"' +
' />');
so the offending url (which can be found with DOMinatorPro fuzzer), is:

http://www.google.com/toolbar/ie/index.html?&gad=bbbb&gkw=yyyy&ovkey=10101010&ovmtc=14141414&ovraw=18181818&

and on any of those parameters can be added an attack payload like:

AAAA"onload="alert(document.domain)"

Remediation

I suggested that the use of encodeURIComponent on user data
    if (w.google_conversion_ad) {
      url = url + "&gad=" + encodeURIComponent(w.google_conversion_ad);
    }
    if (w.google_conversion_key) {
      url = url + "&gkw=" +
encodeURIComponent(w.google_conversion_key);
    }
    if (w.google_conversion_mtc) {
      url = url + "&gmtc=" +
encodeURIComponent(w.google_conversion_mtc);
    }
    if (w.google_conversion_raw) {
      url = url + "&graw=" +
encodeURIComponent(w.google_conversion_raw);
    }
    if (w.google_conversion_domain) {
      url = url + "&dom=" +
encodeURIComponent(w.google_conversion_domain);
    }

would have solved the problem.

Anyway, Google fixed that by removing that script for good, which is a solution as well! :)

Conclusions 

As already said in my previous post, I still see DOM based XSS all around with little awareness and difficulties by all actors in SDLC in identifying them.
DOMinatorPro can really help in finding DOM based XSS and it does that by helping testers, developers or QA users by trying to give the information they need by adapting to the knowledge they have.

Give DOMinatorPro a Try

Do you still trust all those 3rd party JavaScripts embedded in your pages ?
Just browse your site with DOMinatorPro or fuzz your pages and see what happens. :)
In case you need help, check out our professional services or just ask for a contact.

Monday, November 5, 2012

DOM XSS on Google Plus One Button

Introduction

DOMinatorPro can be very useful to find DOM Based XSS on complex JavaScript web applications. This post will describe a Cross Origin Resource Sharing (CORS) abuse exploiting a flaw in the JavaScript Plus One code on plus.google.com.
Just to be clear, yes, it's the +1 button present on billions of pages around the internet.
The issue affected the context of https://plus.google.com which is the context of the social network.

Before going further with any details, a picture is worth a thousand words:



In order to better explain the issue and show how DOMinatorPro helped me in finding the problem, and since a video is worth a thousand pictures, I recorded a video on Youtube MindedSecurity channel.






In the video I deliberately chose to not show a single line of JavaScript in order to demonstrate what DOMinatorPro can do for a tester with little knowledge of JavaScript.

In this post, on the other hand, I'd like to discuss about how the input was treated and how Google fixed the issue with input validation.

Code Issue Details

The offending URL in a simplified version was:
https://plusone.google.com/_/+1/fastbutton?url=http://www.example.com&ic=1&jsh=m;/_/apps-static/_/js/gapi/__features__/rt=j/ver=ZZZZ/sv=1/am=!YYYY/d=1/rs=XXX

First of all, a throw "Bad URL " exception can be spotted on line 425, which actually controls for the presence of multiple callbacks (/cb=/) in 'l' variable and  for the presence of classic  /[@"'<>#\?&%]/ metacharacters in 'ga'. If some of those conditions are satisfied then an exception (Bad URL) is thrown. 
That is called data validation.
 
420 d = m.split(";");
421 d = (i = M[d.shift()]) &&  i(d);
422 if (!d) throw "Bad hint:" + m;
423 i = d = d[q]("__features__", T(r))[q](/\/$/, "") + 
                   (e[s] ? "/ed=1/exm=" + T(e) : "")
                   + ("/cb=gapi." + J);
424 l = i.match(ha); // "https://apis.google.com/TAINTED/cb=gapi.loaded_0".match(/\/cb=/g)
425 if (!l || !(1 === l[s] && 
                 ga[p](i) && !fa[p](i)))
                      throw "Bad URL " + d;
426 e[k].apply(e, r);
427 L("ml0", r, I);
428 c[R.f] || t.___gapisync ?
     (c = d, "loading" != u.readyState ? 
     W(c) :
     u.write("<" + S + ' src="' + encodeURI(c) + '"></' + S + ">")) :
     W(d, c, J) 
....

Line 428 is the call to the function that performs a XMLHttpRequest. By following the flow on Line 532 (beautified) the 'l' variable is tainted and it's the one that is traced by DOMinatorPro, originating by the location.href jsh parameter:

starting from: jsh=m;/_/apps-static/_/js/gapi/....

becomes "https://apis.google.com/_/apps-static/_/js/gapi/..../cb=gapi.loaded_0" and l[q] is the replace function :

function W(){
...
531 a = v.XMLHttpRequest,
532 l = l[q](/^https?:\/\/[^\/]+\//, "/"), 
533 m = new a;
534 m.open("GET", l, f)
...
}
So on line 532 https://apis.google.com/ is removed and 'l' becomes:

"/_/apps-static/_/js/gapi/..../cb=gapi.loaded_0"

The reason why there is execution is that the response is evaluated using the following code:

B=function(a,b,c){v.execScript?v.execScript(b,"JavaScript"):c?a.eval(b):
 (a=a.document,c=a.createElement("script"),c.defer=i,
 c.appendChild(a.createTextNode(b)...
Now, about the fix, I suggested Google to perform some input validation using A tag properties,
var aa=document.createElement("a");
aa.href=untrustedURL;

and then use aa.pathname to be sure it's the browser doing the parsing job but probably it does not work perfectly for all browsers.

In fact Google devs decided to add more data validation

if (!l || !(1 === l[v] && ha[q](d) && 
            ga[q](d) && h && 1 === h[v]))
  throw "Bad URL " + a;
that code changes one check and adds another condition, to the previous one we already discussed.
In particular:
 
ga[q](d) changes from /[@"'><#\?&%]/ (blacklist) 
                 to  /^[\/_a-zA-Z0-9,.\-!:=]+$/ (whitelist)
 
And  
1 === h[v] has been added and means if there is 
            only one "//"  (like http://  )
Which seems pretty solid to me, at least in the context of this specific issue; of course, bypasses are always around the corner, but I'm sure Google security guys took the best effort to be sure it's safe!

Conclusions

DOM Based XSS still remains quite untested, and that's because JavaScript is not easy to analyze in complex scenarios.
DOMinatorPro can really help in finding issue in the easy-to-hard-to-identify range of DOM Based XSS category, because DOMinatorPro is not as simple as you might think, it's a complex piece of software and with a large knowledge base in it.

Tuesday, October 9, 2012

Stored DOM Based Cross Site Scripting

Since the very first release of DOMinatorPro, there is an 'S' little button in the right down corner:


Q: What does it mean?
A: First of all, I'd say, it actually means that there's another feature that makes DOMinatorPro a bleeding edge tool for finding DOM Based XSS :).

The Stored Strings tainting is a very interesting feature that DOMinatorPro implements for tracking stored DOM Based Cross Site Scripting issues.

Think about the following scenery.

Pseudo code:
  setName.do
String name=getFromParameter("name"); saveOnDB(name);
  getName.do
String name = getNameFromDB(); // escape the source (name) from DB so no stored XSS is there String jsEscape=encodeForJavaScript(name); print "<script>\n"; // No problem here since it's escaped. print "var aname='({\"aName\":\""+jsEscape+"\"})';"; print "eval(aname);\n"; print "</script>";
So we'll get in the getName.do page :
.. <script> var aname='({"aName":"PATTERN"})'; eval(aname); </script> ..
At this point you surely understand the issue in the flow:

Step 1. Attacker sends name=PATTERN

  

Step 2. Victim visits a page with the flawed Js.




The attacker can't directly get out from the string since it's supposed to be correctly escaped, so that a payload like name=testPATTERN"'> will become:

var aName="testPATTERN\x22\x27\x3c"; ..
Which is not directly exploitable, but if that same variable is used as argument for a Function or eval, or innerHTML or some of the sinks described on DOMXSS Wiki (contribute please), then it's an exploitable issue.

No existing tool is able to trace patterns like that during JavaScript execution but DOMinatorPro.
What the tester has to do is to turn on tainting on Stored Strings and set the pattern which has to be traced using the settings:


Finally, the user will just have to create the scenario by browsing the application with DOMinatorPro.
And she'll get some output like the following:


Where StoredTainted is the constant string transformed as tainted on the fly.

There are several interesting possibilities by using the tainted stored strings, like applying the same checks on responses from XMLHttpRequests.
But that's food for another blog post.

Feedbacks  are, as usual really welcome!

Ps. If you're a licensed user remember to update the DOMinatorPro Extension to the latest one from your dominator downloads page.

Monday, October 8, 2012

Two updates for DOMinatorPro Suite


As some of you already knows DOMinatorPro Suite consists in two parts, one opensource named DOMinatorCore,based on Mozilla Firefox, hosted on GitHub and a commercial, proprietary AddOn named DOMinatorPro Extension.

Before all words and phrases, here's a MacOs screenshot anticipation of the fully updated DOMinatorPro Suite:



Some very interesting new features have been added, I really hope you'll be interested in trying them.
Bottom line: new versions of both pieces of the suite are out and here is the list of changes.

DOMinatorCore 

Product: DOMinatorCore
Date: 06/10/2012
Version: 0.9.6
  • Finally a MacOs version is available for download!Register or go to your DOMinatorPro personal page and download it!
  • A small but significant improvement in taint propagation  about the creation on the fly of objects via JSON or eval result in tainted values or key name.
var TaintedString='{"k1":"V1PATTERN","k2PATTERN":"V2"}';
var newObj = eval('('+TaintedString+')');
//Obj.keys(newObj)[1].tainted & newObj.k1.tainted are now true; 
Object.keys(newObj).map(
    function(a,b) {
     console.log(a,a.tainted,newObj[a],newObj[a].tainted)
    }
  )
Where PATTERN is a customizable RegEx pattern that triggers the creation of Tainted Stored Strings. We'll blog about the so called Tainted Stored Strings in the next days.
Previously, it would have been triggered only the eval alert on the Stored String if the PATTERN matched.

DOMinatorPro Extension

DOMinatorPro Extension on the other hand has important changes.

Product: DOMinatorPro Extension
Date: 06/10/2012
Version: 0.9.1.2

Tainting

  • ResponseText can be now set as tainted according to Stored Taint functionality.
  • Fixed Firefox bug about location.pathname
  • Added checks for uncontrollable inputElements like checkbox or radio buttons.
  • Fixed jQuery double log for some sink
  • jQuery alerts are shown with jQuery version used, since it can make the difference.
  • Improved jQuery tests and noconflict wrap.
  • location.pathname now returns the pathinfo part with ';'.
  • Hidden and unusable input tag values are now exluded from sources (radio buttons, textbox)

Analysis Engine

  • Improved url building algo in the fuzzer.
  • Experimental Regular Expression check for False Negative / False Positives.

User Interface

  • Now DOMinatorPro has a starting page about:dominator.
  • DOMinatorPro Settings UI are now exposed.
  • We are now able to remove selected results from the log.
  • Removed StackTrace Button since it's handled automatically by sink events.

Automation

  • Added first support to selenium.
  • Remote Alerting send Native JSON.

Knowledge base

  • Knowledge base improvements. 

Most of the changes in the code probably should require a blog post and a video. I'll try to cover some of the more interesting parts about them in the next days!

For any question or request feel free to drop us a line at dominator at mindedsecurity dot com.

Ps. Maybe some already registered trial user will complain about the impossibility to download the addon update, you can download the full suite which comes with a version close to the up to date.


Thursday, September 27, 2012

Analysis of Dom Xss vulnerability in a Facebook Like Button implementation

Note: The following vulnerability is now patched. Thanks to Matt, Charlie and to the Addthis.com team that released a patch yesterday after receiving our advisory.


Description

I like very much facebook, and I like clicking on facebook like buttons like the one below. Addthis.com has its own implementation of Facebook Like Button and is very used among internet websites. They estimate that unique websites around the world are several millions.

A Facebook Like Button in a Share Widget Bar:



You can find some background information already in one of our previous posts:

•    http://blog.mindedsecurity.com/2012/09/temporary-patch-for-dom-xss-0day-in.html

Proof of Concept

http://www.website-with-addthis-widget.con/#"></fb:like><img/src="aaa"/onerror="alert('DomXss Found!')

Note: This reflected dombased cross site scripting (before the patch) was present in a tremendous number of websites


Vulnerable Code


if (F.href === _1) {
d = _8.util.clone(E.share.url_transforms || {});
d.defrag = 1;
F.href = _8.track.mgu(E.share.url, d);//-- Location
}
for (A in F) {
B += " " + A + "=\"" + F[A] + "\"";//-- Attribute Set
}
if (!E.share.xid) {
E.share.xid = _8.util.cuid();
}
f[F.href] = {};
for (A in E.share) {
f[F.href][A] = E.share[A];&nbsp; 
}
G.innerHTML = "<fb:like br="br" 
ref="\">_8.share.gcp(E.share, E.conf,".like").replace(",", "_") 
+ "\" " + B + "</fb:like>"; //-- DomXss
p(G);

Analysis and discovery with DOMinatorPro

Even if to the reader this issue seems like a common cross site scripting, finding such kind of security issues in Javascript code (aka DomXss) is an extremely complex task.

This is why our Advanced Research team developed DOMinatorPro. DOMinatorPro can be downloaded from the following dedicated website: http://dominator.mindedsecurity.com.

DOMinatorPro is a Free Opensource Project with Commercial Extensions. Commercial extensions have a 15 days Free Trial Period.

The vulnerability was in ONE of the scripts loaded by the “addthis_widget.js”  script available online at “http://s7.addthis.com/js/300/addthis_widget.js”. As you can see multiple scripts are loaded and the scripts are compressed and obfuscated , giving to human security reviewers a painful and a very long and time comsuming task to accomplish.

Note: The following part is taken from the DOMinatorPro user manual and shows a similar vulnerability in a demo context. In DOMinatorPro user manual you can find sample cases to help you understand the cause of the vulnerability for producing solid Javascript patches.

By the way, when browsing to a website with a vulnerable “Facebook - Like Button” with DOMinatorPro tool you will see in a couple of seconds the following 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).
Important Note: Sink describes where the vulnerability is and the Source is where the controllable input comes from.
 

Summary of the issue: HTML injection vulnerability coming from a user supplied input location.href (URL)

 Source History

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

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 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="aaa"/onerror="alert('DomXss Found!')">
Important Note: Thanks to DOMinatorPro Browser emulation feature we can mimic different browser insecure behaviors. This permits to show developers the vulnerability inside DOMinatorPro/Firefox, even if the previous exploit works only under Internet Explorer.

Call Stack 

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

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.

Fixing

Correct fixing at line 116:
•    Use the “encodeURIComponent()” function.