Looking for web vulnerabilities using the scanner

For an effective web application penetration test, you will need to perform both a manual test and an automated test. If you only do one of them, you're not doing the right thing. This has been a debate, and sometimes, I see teams relying on fancy, automated tools, because they lack the knowledge for manual tests. On the other hand, I've seen teams with sky high egos; they think that manual tests are for the elite, and that those tests should be enough. My philosophy is that you need both. In this section, I will show you the automated method to scan for vulnerabilities. The manual method will be covered in an upcoming chapter. 

In Burp, the first type of scan is the passive scan, which involves analyzing the HTTP messages for evidence of certain types of vulnerabilities. It does not send any additional requests to the server. This can be accomplished when you're browsing manually, and you can trigger it by right-clicking on the target scope on the site map. Then, from the menu, click on Passively scan this branch.

The second scan technique is the one that really automates the fuzzing to find web application vulnerabilities:

1. To execute it, simply right-click on the directory that you wish to test, and then, from the menu, click on Actively scan this branch. After this action, a pop-up menu will appear. In general, I use the options that you can see in the following screenshot:

1. Click on Next, and a second step will show you the list of files that will be scanned in this process. Check them out, then click on the OK button to start the scanner:

1. To check out the progress of this event, select the Scanner tab, then click on the Scan queue sub-tab. At first, you will see that the scanner has started to look for vulnerabilities; you can use the Status column as an indicator of the progress of the scan:

1. Later, when all of the statuses turn into a Finished state, you can start taking a peek at each item by double-clicking to see the results:

This dialog window (seen in the preceding screenshot) allows you to analyze the Request that Burp generated to produce the error Response. Later, you will use the Repeater tab to double-check the results and make sure that there's not a false positive.

1. Finally, it's time to generate a report. To do this, go back to the Target tab and select your target application root directory (in our case, it's going to be the mutillidae folder). Right-click and select Issues from the menu, then click on Report issues for this branch:

1. After that, you will have a few dialog windows to fill out; they're pretty straightforward. I usually just choose the default options until the report is generated in an HTML format:

At this stage, your role is to identify the false positives. Logically speaking, when you see Burp telling you that the confidence is Certain that is more than 90%, it is a real flaw. When the confidence is Firm, it means 60% it's not a false positive and Tentative most probably is a false positive. Flaws and vulnerabilities are called issues in Burp—just to make sure that you understand the terminology this application uses to identify web application vulnerabilities.

Please do not copy the Burp report and give it to your client without checking for false positives; if you want to have a good reputation, then don't. I've seen reports from companies where the flaws were copied directly from the report—I've recognized the fonts in the Burp reports, and then you can assume what I did say when I saw that report.