Introduction To Burp Suite Scan Profiles
With the introduction of the Configuration Library in Burp Suite 2.0’s release, we’ve been creating more and more predefined templates to use during our web application penetration tests. These templates help us quickly fuzz an application’s endpoints, or narrow our scope to just certain parameters that we’ve keyed in on to being potentially vulnerable.
Compared to launching a traditional ‘full’ scan against every single dynamic page of an application, which may result in tens or hundreds of thousands of requests, our engagements tend to operate a bit more efficiently by leveraging these scan profiles.
Detection of Cross-Site Scripting (XSS)
Example Workflow:
When analyzing an application for vulnerabilities one may typically start off by selecting the following profile for every single page, “Audit checks – all except JavaScript analysis”. Often, one may opt to include the JavaScript analysis as well for each page.
After running this scan profile against a reflected Cross-Site Scripting (XSS) endpoint, such as on the Damn Vulnerable Web Application (DVWA), Burp Suite successfully identifies the XSS vulnerability on the page. However, it took 1991 requests to finish this scan since we were analyzing the entire application for every vulnerability from XSS to SQLi.
While we were successful in our goal, could we be more efficient? What if we had already scanned the application (albeit, a different page) with the ‘large’ default profile once. Now that we discovered this potentially vulnerable page, do we really need to scan the entire page for every vulnerability class when we could just hunt for XSS directly? This is the question that separates the ‘tool’ from the ‘pentester’. For instance, a page vulnerable to XSS may not typically be vulnerable to Command Injection… but a page vulnerable to Command Injection is often vulnerable to XSS. By narrowing your scope to just specific vulnerability classes to hunt for, based on your knowledge of the application architecture, you can more efficiently identify those vulnerabilities with fewer requests.
Efficient Detection of Cross-Site Scripting (XSS)
Example Workflow:
Let’s try to be more efficient this time with our approach to XSS detection. Rather than launching a full scan, we can create a scan profile just for XSS-type attacks. By utilizing the Burp Suite extension Reflected Parameters we can quickly identify potential locations (which Burp Suite has captured during the crawling phase) within an application’s scope where XSS might exist.
From there, we can quickly identify potential targets. To narrow our scan scope even further, we send the request to Burp Suite Intruder, define an insertion point around the parameter(s), then right-click > Scan defined insertion points > Open scan launcher.
Within the scan configuration, we select a pre-defined “XSS & Friends – No Cookie” template. Note, we don’t often scan cookies when hunting for XSS in the first round of testing. Of course, we also have an “XSS & Friends – With Cookies” template with cookie support.
As you can see, both scan profiles ended up in the same place identifying the reflected XSS vulnerability. However, our custom scan template which only scans for XSS identified the issue in significantly fewer requests; just 3% of the total of the default scan. In our experience, on a live engagement, it is incredibly useful to have a more efficient scan. Any number of factors may limit the amount of time it takes to get through the ‘large’ default scan such as the environment you are scanning, the vulnerability class you’re hunting for, and any rate-limiting that may be in place. If you have to execute the large scan profile for every page of a gigantic application, it may never complete in the engagement timeframe.
Creating BurpSuite Scan Profile Templates
To create a similar template, open the Configuration Library within Burp Suite under the “Burp” file menu. Below, we have several predefined templates for a range of vulnerabilities and actions.
Next, click on the “New” button and create a new configuration with a catchy name. Under “Select individual issues”, you can narrow down Burp Suites payloads to just a select few. In our profile, we like to select all of the XSS issues, as well as a couple of other payloads such as template injection and some XML payloads.
You may have noticed that we have named our profile with “No Cookies”. For our personal application pentesting workflow, we typically do not initially hunt for vulnerabilities within cookies. We save cookie security testing for a different portion of our engagement, as tampering with cookies will often involve killing the session and hindering scan progress. An example scan configuration below removes cookies from the scan configuration insertion points.
Other BurpSuite Examples
Another useful scan profile we’ve built out is a SQL Injection scan configuration which is useful for fuzzing for SQL Injection.
Similarly, a scan template for path traversal can easily be created within BurpSuite’s scan configuration library.
That’s all there is to it! Once you have created several scan configurations, you can then fuzz with them to your heart’s desire throughout your pentest as you identify potentially vulnerable entry points.
Closing Thoughts
We hope that Portswigger continues to flesh out and build new features into the Configuration Library, as the power of templates will make application penetration testing more robust. Of course, these scan profile templates do not replace the need for manual fuzzing and validation, but they are extremely useful for narrowing down the scope of an application’s vulnerable components by helping generate test cases to aid with discovering vulnerabilities.
A couple of ideas we would love to see implemented into the Configuration Library:
- More details within the exported JSON structure. It’s a bit unclear which vulnerability has been loaded into the scan profile since only a numerical ID is used
- The ability to add custom wordlists to certain scan profiles would be nice (such as path manipulation)
- Scan templates pre-populated with the target scope via the project options JSON structure would be useful to set up an application scan quicker
What else would you like to see implemented to make things a little more efficient? Give this a try and let us know your thoughts.
