Researcher
**Published:** 23 April 2025 at 13:17 UTC
**Updated:** 23 April 2025 at 13:17 UTC
**Tired of repeating yourself? Automate your web security audit trail. In this post I’ll introduce a new Burp AI extension that takes the boring bits out of your pen test.**
Web security testing can be a grind: documenting every step, writing the same notes over and over, and repeating it all across every engagement. But what if your workflow could document itself – while you hacked?
Meet “Document My Pentest”, your silent co-analyst for security testing. It’s an open-source Burp Suite extension that watches your requests in real time, understands what you’re probing for, and automatically builds a clean, structured record of your findings – capturing exactly what you did and how you did it. When you’re ready, hand it off to AI and generate a report. No more boring note taking. Just results.
The PortSwigger research team has been exploring new AI extensions using Burp AI features , and it’s surprisingly quick to get a functional prototype up and running. Within just a few days, I had a working extension.
I quickly learned that the AI isn’t very good at analysing a whole request and response, especially for vulnerabilities like XSS. It was good at spotting Path Traversal where a response gave a clear indication that it had worked because the directory listing was displayed.
With this in mind I began to come up with a strategy to identify reflected data. My first thought to accomplish this was to use canaries and look at where the canary is reflected but there are a couple of issues here: a) We’d need to send an extra request for every request and b) We’d have to alter the user sent request. Then I thought why don’t we just use the tested input as the canary and translate it to a regular expression. It worked like this:
Consider the input “ this can be transformed in a plethora of ways but often the alphanumeric characters will stay consistent, so I wrote an input to regex translator which transforms the input into:
`.{1,6}script.{1,6}alert.{1,6}1.{1,6}.{1,6}.{1,6}script.{1,6}`
This would mean it would match transformations like:
`
%3Cscript%3Ealert(1)%3C%2Fscript%3E
%253Cscript%253Ealert(1)%253C%252Fscript%253E`
This can give the AI the exact transformation and extract a more focussed part of the reflection enabling the AI to even quote what the input was transformed to without any specific instructions. After a lot of testing this seemed to work pretty well but we quickly found that it wasn’t suitable for other attacks such as Request Smuggling. In this case where parameter/header modifications couldn’t be detected we decided to send the whole request and response with a different AI prompt that produced much better results.
Whilst building this extension I often found the AI would misidentify vulnerabilities and this was due to the instructions given in the prompt. For example:
“*Note* if HTML entities are found they very rarely indicate an XSS vulnerability.”
The problem with this prompt is that it is uncertain to the AI if it’s a vulnerability or not. My thinking was that you can use entities inside “srcdoc” attributes to cause XSS but this vague language causes the LLM to label vulnerabilities as potential XSS even when it’s HTML encoded. The solution to this is to create more precise language in the prompt:
“If the response reflection contains HTML-encoded input (e.g., `