Burp Suite can find Cross-Site Scripting (XSS) vulnerabilities by actively injecting payloads into web application parameters and observing how the application reflects them.
Let’s see Burp Suite in action. Imagine you’re testing a simple search functionality on a website.
First, you’d navigate to the website in your browser, ensuring Burp Suite is set up as your proxy. Then, you’d perform a search.
Browser: https://vulnerable-site.com/search?query=test
Burp Suite intercepts this request. You’d then send this request to Burp’s "Intruder" tool.
Burp Suite - Target Tab:
- Right-click the request -> "Do the same thing again" -> "Intruder".
In Intruder, you’ll see the request. We want to test the query parameter for XSS.
Burp Suite - Intruder Tab:
- Positions Tab:
- Select "Sniper" attack type.
- Click "Clear §" to remove all default payload markers.
- Manually select the value of the
queryparameter (testin this example) and click "Add §".
Now, we need to define the payloads. Burp has built-in lists for XSS.
Burp Suite - Intruder Tab:
- Payloads Tab:
- Payload type: "Simple list".
- Payload Options -> "Load…".
- Navigate to Burp’s built-in wordlists:
Extensions/BurpSuiteProfessional/payloads/XSS.txt. Select this file.
This XSS.txt file contains a variety of common XSS payloads, like <script>alert(1)</script>, "><script>alert(1)</script>, and so on.
- Click "Start attack".
Burp will now send each payload from the list to the query parameter, one by one, and record the server’s response. We’re looking for responses that indicate our injected script was executed.
The key here is to identify which payloads caused a difference in the response that suggests execution. This usually means looking for:
- Reflected HTML: The payload appears in the HTML response, potentially within tags that would execute it.
- Content Length Differences: A sudden, significant increase in response size might indicate a script was embedded and rendered.
- Specific Status Codes: While less common for XSS, an unusual status code could be a hint.
The most reliable indicator is the presence of the payload itself, especially if it’s enclosed within HTML tags or attributes in the response.
Burp Suite - Intruder Results Tab:
- Sort by "Length" or manually inspect the "Response" column for payloads like
<script>alert(1)</script>appearing directly in the HTML. - Pay close attention to the "Render" tab in the Response viewer for any payload that seems to be reflected. If you see
alert(1)pop up in the rendered response, you’ve found an XSS vulnerability.
The mental model is that you’re a digital alchemist, taking ordinary user inputs (like search terms) and poisoning them with tiny, potent code snippets. You then watch the application’s reaction: does it vomit the poison back out in a way that a browser would interpret as instructions?
The query parameter in https://vulnerable-site.com/search?query=test is a common injection point. If the server takes the test value and directly inserts it into the HTML response without sanitization, like <div>You searched for: test</div>, and you inject <script>alert(1)</script>, the response becomes <div>You searched for: <script>alert(1)</script></div>. When the browser renders this, it executes alert(1).
A crucial detail most people miss is the subtle difference between reflected and stored XSS. While Intruder is excellent for reflected XSS (where the payload comes directly back in the response to the same request), it’s less direct for stored XSS. For stored XSS, you’d typically use Intruder to inject payloads into forms that save data (like comments or user profiles), and then you’d need to revisit the page where that data is displayed to see if the injected script executes. Burp’s "Scanner" tool is often more automated for finding stored XSS.
The next step after finding an XSS vulnerability is to understand its impact and how to exploit it further.