Exploitation

Welcome back to Cross-Site Scripting session. In this second part, we will exploit a cross-site scripting vulnerability in our target application. We will jump straight to our intentionally vulnerable application and then move on to the mitigation part. As discussed in the previous part, we will test the product search feature and understand how it works and whether it is vulnerable to cross-site scripting. Let’s pop up developer tools to inspect the network traffic.

Note that our search keyword now also appears in the URL and in the page’s body.

In the network, we can see a request to a search end point with a q parameter, but it does not include our search keywords.

In fact, the response returns all products, and then they are filtered client side.

If we find a vulnerability, then it will be a client XXS, as discussed before. Let’s have a look at the page’s DOM.

Using another search keyword, we see that the DOM node is updated.

Let’s use the XXS payload we used as example in the first part of this session.

The payload also appears in the URL, but this time, it isn’t visible next to the search results title. Nevertheless, we can find it in the DOM.

The model box was not triggered, meaning that our payload was not executed. Some frameworks have XXS prevention mechanisms, and this may be the case. In such cases, we should try to bypass such mechanisms testing different payloads.