If you're not regularly using Burp Scanner as part of your manual testing workflow, you're wasting far more time and effort than you realize. By taking advantage of a couple of lesser-known features, you can supplement your own expert knowledge and intuition with Burp Scanner's methodical approach to testing. Not only will this help you cover more ground, you'll be able to spend your time where it matters rather than on tedious preliminary work.
When you come across an interesting function or behavior, your first instinct may be to send the relevant requests to Repeater or Intruder and investigate further. It's often beneficial to send the request to Burp Scanner too. It can get to work on the more repetitive aspects of testing while you put your skills to better use elsewhere.
Go to Proxy > Intercept and launch Burp's browser. Use it to access the following lab:
https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responsesThis should open a deliberately vulnerable online store.
Visit one of the product pages.
In Burp, go to the Proxy > HTTP history tab. Observe that the resulting GET /product?productId=X request contains a query parameter and a couple of cookies, all of which are user controllable. This makes it a good place to start looking for input-based vulnerabilities.
Right-click on this request, either in the message editor panel or from the list of interactions, and select Do active scan.
Burp Scanner immediately begins running an audit-only scan using its default configuration.
Alternatively, if you want more control over how the request is scanned, right-click and select Scan. This way, the scan launcher opens, allowing you to adjust the configuration before the scan starts.
You've already learned how to scan specific requests, but you can optimize this even further by only scanning with specific insertion points that you think might be of interest.
Send the same GET request we used in the previous tutorial to Burp Intruder and go to the Intruder tab.
As you can see, Burp Intruder has identified three potential insertion points already, and Burp Scanner uses even more than this by default.
Clear the default payload positions and set new ones for the productId and TrackingID only.
Right-click on the request and select Scan defined insertion points.
From here, you can launch a scan that will only place payloads in the two positions you've explicitly defined. This can massively reduce the number of requests made by Burp Scanner.
This approach can yield results incredibly quickly, giving you something to work with in just a couple of seconds. From the Dashboard tab, notice that the scan is already finished and has found a SQL injection vulnerability.
You've now learned how to use Burp Scanner during manual testing.
In addition to what you've learned so far, here are a few extra tips: