# DOM XSS in document.write sink using source location.search

![](https://telegra.ph/file/82ef696c6242703c71e50.png align="left")

This is a writeup for a challenge from PortSwigger's [Web Security Academy](https://portswigger.net/web-security/). In this one, we will learn how a DOM Cross Site Scripting (XSS) vulnerability works, how it can be exploited and what an attacker can gain out of it. In the previous writeups we were looking at Stored and Reflected XSS

### **Objective**

This lab contains a [DOM-based cross-site scripting](https://portswigger.net/web-security/cross-site-scripting/dom-based) vulnerability in the search query tracking functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from [location.search](http://location.search), which you can control using the website URL.

To solve this lab, perform a [cross-site scripting](https://portswigger.net/web-security/cross-site-scripting) attack that calls the `alert` function.

### **Solving the challenge**

Starting up the box:

![](https://telegra.ph/file/41fa980da089e4f528e77.png align="left")

Let's try to search for something

![](https://telegra.ph/file/26a1f8db45d342e257d4d.png align="left")

If we inspect the source code of the page, we will learn that our search query ended up in the `img` tag inside `<script>` section

![](https://telegra.ph/file/74f2a327fc711ce563efe.png align="left")

We can break that `img` tag with the `"` symbol, and put our arbitrary code there:

![](https://telegra.ph/file/0cf7ec5bd3e451a0c1985.png align="left")

And we got our session cookie alerted to the screen.

If we explore the code one more time, we can see that our search populated and executed one more code section, that executed an alert when the browser rendered this element:

![](https://telegra.ph/file/0534200183acd5b2675f7.png align="left")