Hi everyone,
I’m writing my final Burp Suite tutorial blog post today! This blog post will explain how to use the Scanner tool in the suite, to see tutorials for other Burp Suite tools please visit the links below:
I’m going to be using the Damn Vulnerable Web Application again today to demonstrate the Scanner tool.
What is the Scanner tool?
The Burp Suite is a collection of tools for web application security testing which includes the Scanner tool (description taken from the Port Swigger website):
Scanner: Burp Scanner is a tool for performing automated discovery of security vulnerabilities in web applications. It is designed to be used by penetration testers, and to fit in closely with your existing techniques and methodologies for performing manual and semi-automated penetration tests of web applications.
Enabling the Burp Suite Proxy
To begin using the Burp Suite to test the Damn Vulnerable Web Application we must configure our web browser to use the Burp Suite as a proxy. The Burp Suite proxy will use port 8080 by default but you can change this if you want to.
You can see in the image below that I have configured Firefox to use the Burp Suite proxy for all traffic.
When you open the Burp Suite proxy tool and check that the proxy is running by clicking on the options tab:
You can see www.2cto.com that the proxy is using the default port:
The proxy is now running and ready to use. You can see that the proxy options tab has quite a few items that we can configure to meet our testing needs. A lot of these items are out side of the scope of this tutorial.
The Burp Suite will now begin logging the requests and responses that pass through the proxy. I have browsed to the DVWA homepage and the Burp Suite proxy has captured the request and response:
The Scanner tool will passively scan all traffic by default and we can see that it has already noticed that our password will be submitted in the clear:
As with just about everything in the Burp Suite you can change this default behaviour by clicking on the live scanning tab.
As you can see in the image above the Scanner tool will passively scan every request and response it sees. It won’t send any additional requests or try to exploit specific vulnerabilities such as SQL Injection until you tell it to. The Scanner tool can be configured to actively scan everything by default which means every web site you visit will be scanned.
The Scanner tool can also be configured to restrict its scanning (both active and passive) to the overall suite scope or a custom scope defined just for the Scanner tool.
The suite scope can be found by clicking on the target tab and then clicking on the scope tab. You can see that we currently have nothing in the suite scope:
I want to scan the Damn Vulnerable Web Application in this tutorial so I need to add it to the scope. To add a site to the suite scope you need to click on the site map tab and right click the site you wish to add to the scope:
The site will now be included in the suite scope:
If you wanted to define a custom scope for the Scanner tool you can do that by clicking the use custom scope radio button on the live scanning tab:
I have defined a custom scope for the active scanner as you can see below:
We could start scanning the Damn Vulnerable Web Application now but let’s explore the Scanner tool options first.
The Scanner tool can be used without changing of the default options but you should always try to configure the options to optimise your scanning, don’t just point and click!
The attack insertion points will tell the Scanner tool where it should try to attack inputs. The Scanner tool can insert into seven different locations as you can see in the images above, the locations are explained below (descriptions taken from the Port Swigger website):
- The values of URL, body and cookie parameters.
- Parameter name – if selected, Burp adds an additional parameter to the request and places attacks into the name of this parameter, often detecting unusual bugs that are missed if only parameter values are tested.
- HTTP headers – if selected, Burp places attacks into the User-Agent and Referer headers, often detecting issues like SQL injection or persistent XSS within logging functionality.
- AMF string parameters – For requests in Action Message Format, Burp places attacks into any string-based data types within the message.
- REST-style URL parameters – if selected, Burp places attacks into each directory or file name within the path portion of the URL.
The next option is the “use intelligent attack selection” option. This option allows the Scanner tool to perform or omit specific attacks based on the insertion points defined above and the content of the requests it sees (description taken from the Port Swigger website):
You can also tell Burp to use “intelligent attack selection”. This option causes Burp to perform or omit each type of server-side check based on the base value of each attack insertion point. For example, if a parameter’s value contains characters that don’t normally appear in filenames, Burp will skip file path traversal checks for this parameter. Using this option can considerably speed up your scans, with minimal risk of missing actual vulnerabilities that exist.
The next two options allow you to optimize your scanning by skipping server side injection attacks for specific parameters or even skip all testing for some parameters.
The Scanner tool can be configured to use many scanning threads at once or as little as one thread. This is useful if you are seeing poor test performance, timeouts etc because a high amount of threads can overwhelm poorly designed sites.
The final part of the options tab allows you to select the attack types that the scanner will use.
The Scanner tool is now configured to scan the Damn Vulnerable Web Application so let’s start the scan!
To being actively scanning the site you need to right click it in the site map and click on “actively scan this host”:
I have used the spider function of the Burp Suite to ensure we are scanning more than just the logon page. The active scanning wizard window will popup when you click on the “actively scan this host” option:
The wizard will allow you to remove items from the scan such as duplicate items or any items which have already been scanned.
The next step in the wizard is confirming the items to scan:
If you click the “ok” button the active scan will start:
The results tab is updated dynamically during the scanning if any issues are found. The results of the Damn Vulnerable Web Application scan can be seen below:
The results of the Damn Vulnerable Web Application scan shows why you cannot take a “point and click” approach to security testing. This is true regardless of the tool being used. The Scanner tool identified 114 XML Injection issues in the Damn Vulnerable Web Application but they are all false positives. To review a specific issue you can select it from the top right panel on the results tab as you can see below:
The request and response can be viewed by clicking on the request and response tabs:
The Scanner tool added ]]>> to the /dvwa GET request and the response included the some XML. The Scanner tool has highlighted the XML in the response from the Damn Vulnerable Web Application as you can see in the second image above. We can see that this finding is a false positive so the Scanner tool allows us to change the severity and confidence rating of each issue. To change the severity and confidence of a particular issue right click it and click on set severity or set confidence:
I have changed the severity and confidence for this issue to False Positive and Certain:
When you are happy with the issues found you can produce a report from the Scanner tool by right clicking the results in the left hand panel and clicking on “report selected issues”:
The reporting wizard will popup and you can choose your reporting format, the level of detail to include in the report and the issue types to include in the report:
I hope you have found this blog post useful and I’m always interested in hearing any feedback you have
摘自 http://hi.baidu.com/evilrapper/blog/item/36553d357e79bb0e90ef3998.html
1495
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
