Example 2
Tracking/analytics script often introduces vulnerable sinks. I found several Microsoft domains
using RIOtracking script where the user input was not properly escaped before being inserted into
the DOM. This resulted in a DOM-based XSS vulnerability; the worst part was that more than
50 Microsoft domains were using the same tracking script, which led to XSS in all the websites/
domains using that tracking script.
The POC was as follows:
◾
www.microsoft.com/en-ca/dynamics/default.aspx?#”>
Web Hacking
◾
381
The main cause of this vulnerability was that the input passed via location.hash was being
executed by a vulnerable sink “Document.write”. The Chrome js console pointed me to line 58
responsible for this vulnerability.
In my research, I found tracking scripts, third-party ad code, to be one of the major causes for
DOM XSS vulnerabilities.
Example 3
Location.search is another common source, which you might often encounter. A friend of mine,
Daniel, found DOM XSS vulnerability in PayPal, where the input was being taken via location.
search, and then by using location.replace (sink), it was being redirected to the user-supplied input.
Vulnerable code
function GetAttach()
{
var strSearch = document.location.search;
strSearch = strSearch.substring(1);
document.location.replace(strSearch);
}
In the first line, the user input taken via location.search is saved into a variable “strSearch”; in the
next line, the substring function is used to extract the part after the question mark (?). In the third
line, it uses the location.replace property to redirect to what was extracted after the question mark.
All we need to do now is add “javascript:alert(0);” after the question mark and when location.
replace would redirect it, the js would be executed.
|
