A Brief XSS Scanning with Burp Suite
Sometimes, as a test engineer, you need to perform a full-scale check of your web application for vulnerabilities.
Web application security testing is not the topic of one article, it takes a whole book. So I will focus only on the example of scanning for XSS (cross-site scripting) with one special tool — Burp Suite.
You can try to find XSS vulnerabilities manually, but it won’t be productive and efficient. Testing for XSS is a kind of brute-force search — a repetitive scanning (or attacking) with changing of various parameters and payloads. Such tasks should be solved with a special tooling that allows us to check hundreds of test cases in a relatively short time.
1. Prepare the Burp Suite
I will use Mac OS Big Sur 11.6.4, Burp Suite Community Edition 2022.3.6 and Firefox 100.0.
- Download and install Burp Suite Community Edition;
- Run Burp Suite Community Edition and choose on the start screen: Temporary project → [Next] → Use Burp defaults → [Start Burp]
- Check Burp’s proxy settings: Proxy → Options → Proxy Listeners. Burp’s proxy should listen 127.0.0.1:8080
4. Install Burp’s certificate for Firefox by instruction;
5. Сonfigure Firefox’s proxy settings: Preferences → General → Network Settings → [Settings…] → choose «Manual Proxy Configuration»: HTTPS = 127.0.0.1 and Port = 8080 → [OK]
6. For further work of the «browser-Burp» bundle you need to turn off the Intercept: Proxy → Intercept → [Intercept is on]. Button should be = [Intercept is off]
Now, when you open a target page (I choose the official site of Formula 1) in Firefox, all connections from the page will pass through Burp and be logged:
Remark: If your target site is an internal environment inside a company’s VPN under IPv6, you should go: Project Options → HTTP → HTTP/2 and turn off «Default to HTTP/2 if the server supports it».
2. Prepare payload
To scan for vulnerabilities you need to have «vectors» for attack. The most significant XSS vectors are listed in OWASP’s XSS Filter Evasion Cheat Sheet.
To have only a few vectors is not enough for such kind of testing — you need different sets of payloads aimed at bypassing certain defensive filters — you do not know in advance which one will «work».
- Cross-site scripting (XSS) cheat sheet
- https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS Injection
3. Start test attack
The most simple attack (or scan) can be made through Burp’s Intruder by this steps:
- Refresh a target page in the browser;
- Open: Burp → Logger;
- Find a root HTTP/HTTPS request to the target page;
- Choose «Send to Intruder» in the request’s menu:
5. Open: Burp → Intruder. You will see the full request which was made by browser. All request’s variables will be marked by
6. Clear all identifiers: [Clear §]
7. Add two identifiers after GET / —
GET /§§ — this means that the values from the payload list will be embedded inside
8. On the «Payloads» tab paste from the buffer or load from a file your payload list:
9. On the «Payloads» tab turn off encoding to use all vectors unchanged;
10. On the «Options» tab reduce the number of retries = 0 (in order not to slow down the run in case of errors) and click [Start attack]:
11. In a new window you will see the progress of your attack:
If the status code will be different from 200 or 404 and the request length will have a suspicious value — this means that you need to look closely at this request and try to reproduce it manually — a bug or vulnerability is somewhere close.
Nothing interesting was found in the example above — it was just an introduction to starting Burp Suite’s scans.
To find something worthwhile you should:
- Take a closer look at the URLs with parameters;
- Attack different request’s values (user-agents, cookies, session_ids or any custom headers);
- Attack requests with authorization;
- Attack POST requests with payloads in a body;
- Combine different payload lists;
- Use SQL injections instead of XSS payloads.
Example of a brief explore:
- There was an odd parameter a tag’s name in the URL:
2. I marked this parameter by identifiers in the Intruder and started attack;
3. I changed a few payload lists until the vector in one of it was triggered 400 status code:
4. Reproducing this request in a browser leads to the error:
This means that the web application does not handle % in URL. The real attacker could use this knowledge to continue the attack.
In case of API testing you can Use Postman Collection Runner as Vulnerability Scanner.