Shulou(Shulou.com)05/31 Report--

This article shows you how to use Burp Suite to attack Web applications, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Summary of web application testing: Web application vulnerabilities cause great risks to enterprise information systems. Many web application vulnerabilities are due to the lack of input filtering in web applications. In short, a Web application takes some form of input from the user and executes that information in the application to provide it with content or to retrieve data from other parts of the system. If the input is not filtered correctly, an attacker can send non-standard input to take advantage of the web application. This article focuses on burpsuite and shows you how to use it to evaluate web applications.

Summary of Burpsuite

Burpsuit has many features including, but not limited to,

Interception Proxy: designed to give the user control over the requests sent to the server.

Repeater: the ability to quickly repeat or modify a specified request.

Intruder: allows automation of custom attacks and payload.

Decoder: decode and encode strings in different formats, URL,BASE64,HTML, etc.

Comparer: highlight the differences between different requests or responses.

Extender: the API interface that extends Burp functionality and many extensions available free of charge through the BApp store.

Spider and Discover Content feature: crawl links on web applications and can be used to dynamically enumerate the contents of non-explicit links to find information.

Scanner (Pro Only): an automatic scanner that checks for vulnerabilities in web applications, XSSSQLi code injection files, etc.

Introduction

Detailed help documentation for Burp can be found below

Http://portswigger.net/burp/help/suite_gettingstarted.html

Burpsuite can be loaded from the java-jar command line. You can allocate the memory needed for your burp by using the option "- Xmx".

Java-jar-Xmx1024m / path/to/burp.jar

Like many interceptor agents, Burp is also driven through GUI, but there are some options that need to be started on the command line through the Extender feature.

Once burpsuite starts, it is recommended that you define the target host in Scope first. You can control the content and other functions displayed in site map. Scope can define the target hostname IP or network scope:

The Proxy tab displays Burp's agent details, intercept options, and HTTP request history. You can see "Intercept is on" below, so any request from the browser will have to click forward manually through Burp's proxy to perform Intercept function will truncate all traffic sent from the browser. Other extensions such as FoxyProxy can be used to specify which URL and IP are blacklisted or whitelisted these lists can bypass the truncation of burp. By configuring Burp's scope and proxy, you can start browsing web applications using your browser and burp, such as you can right-click on the Site Map target and pop-up menu options. In this view you can see the directory structure and resources of the web application. By right-clicking URL or resources you can use several options to call other functions such as Burp's spider function or perform active scanning prompt in order to make it easier to focus on the target web application you can click the "Filter" menu to show only the content within the scope activating Burp's spider function will crawl links to web applications with a default crawl link depth of 5 but these options are configured in the "spider" tab. Once you truncate the web application, all requests and responses will be recorded in the "proxy" tab. You can highlight a request to make it stand out and leave a comment on Burp's Engagement Tools in later analysis.

   Burpsuite provides a lot of useful functionality under its Engagement Tools right-click on the target site view > Engagement Tools. From here you can select "Analysis Target" to analyze the target. This function provides you with link parameters and counts of static and dynamic content. Knowing this information is very useful for the evaluation target. The more links, parameters, and dynamic content you have, the more points you inject into fuzz.

   you can see some other features such as "Schedule Task" scheduled tasks that allow you to scan actively on a regular basis in the screenshot below. This feature is especially useful if the client wants to perform automated tests for certain hours of the day.

Discovering Unlinked Content found non-explicitly linked content

One of the problems    will face when testing web applications is enumerating content that does not use explicit links. This can be a time-consuming approach because it relies mainly on brute force guessing to make requests and see if the resource exists on the server. For example, the "/ tmp/" directory is not in any link to the web application but will get a response if the request / tmp/ directory is sent. We have many other options to solve this problem.

Take advantage of the Discover Content function of Burp.

Use other scanners such as Niktow3afZAP to detect some default resources.

Use the Intruder function of DirBuster or Burp to violently guess resources based on a fixed list.

All of these methods are time-consuming and may not actually find anything, so you don't have to keep DirBuster running all day depending on the time and scope of the test. In general, when you do another manual test, it will automatically run in the background.

   below is an example of trying to dynamically enumerate the contents of non-explicit links by calling the Discover Content function of Burp

Decoder and Comparer (codecs and comparators) for Burp

When you start testing WEB applications, you will find that you often need to decode or encode strings into different formats. It's useful when trying to bypass some simple waf. The following example is to use Burp's decoder to perform URL encoding in addition to other codec options.

Burp's Comparer feature allows you to quickly compare requests or responses and highlight the differences between them

Extender extension of Burp

Extension capabilities provide powerful API interface development by using scripting languages to develop additional functionality. Many of the extensions are written in python and are available free of charge through Burp's app store. A very useful extension is Carbonator, which allows you to fully automate brupspider > scan > report on the command line.

Burp's Intruder brute force cracking

Another option is to take advantage of Burp's intruder feature, which can use a request and allow the user to modify the request to define a variety of payload injection points. A common use case is that parameter values in iterative requests are used to see how web applications respond, such as get / product.php?item=1. You might want to use intruder checks to compare the differences between 1-1000 responses. You can also use the requested resource as the location to be modified. Next we will demonstrate this by traversing a directory dictionary

1. Specify a request and select "Send to Intruder" which will bring up the following window under the "intruder" tab. The highlighted area is the part of the request that will use the "sniper" payload for violent guessing.

two。 Next up is the payload tab, where you can load a dictionary for brute force guessing.

3. Select "Intruder > Start Attack" to start the attack. The next results window displays the created request and the HTTP status code. As we can see, we can enumerate some of the other resources that spider has not discovered.

In addition to using Burp, it is recommended that you run an intermediate scanner in the background to check some default configurations and resources. The following is an example of using Nikto. You can also consider other scanning tools such as ZAPw3afGrendal. As we can see, Nikto has found more interesting things waiting for us to investigate, such as / tmp/ and / test/:.

After preliminary reconnaissance, we want to start an active scan that allows Burp to test known content to find vulnerabilities. Mainly through the Burp input content HTML, javascript, SQL syntax, system commands and so on to do a lot of work and monitor how the application responds. Like any Web application vulnerability scanner, Burp reports reports that require manual verification. To start an active scan, right-click the URL or resource on the site map and select "Actively scan this host" will pop up the following active scan wizard

Scan times in Web applications may vary from Web application to Web application. In some cases, the automatic scan time for Web applications may range from a few hours to a few days. The link count enumerated during the scan is a good indicator of the potential scan duration. The following window shows an enumeration of 1515 links, but few parameters are used to test the input. Links without parameters will reduce the number of Burp requests for each link, so the scan time is shorter.

Another key factor for    in evaluating proactive scanning web applications is form submission. When you actively scan web applications, you may generate a large number of log trouble ticket jobs, etc., depending on the web application and the functions provided to users. If not within the scope of the assessment, these conditions should be closely monitored to prevent a denial of service DoS condition.

After the    scan starts, you can view the results and status by jumping to the scanner tab in Burp.

As you start to display the results, you can start to check some results.

Analyze scan results and manual testing

It is usually a good idea to verify the Burp scan results to determine if the results are misreported and fully understood. Start by selecting the results of discovery, such as "Cross-site scripting (reflected)", and then select and view the details that affect vulnerability assessment in its requests and responses. The first thing to check for XSS is to repeat the request in the browser and see if the script is running. You can right-click the request body and select "Request in browser"

Viewing the response in the browser is useful to determine whether the tag is correct. Because the XSS evaluation results are related to the code executed in the client browser, it is important to choose to manually validate the findings before relying on the scanner logic.

Another common feature of    Burp is that "Repeater" is usually used to validate results or manually search for other results. Just right-click the body of the request and select "Send to Repeater"

In the Repeater interface you can modify the request and quickly resend the request to the Web application.

Reflective XSS can be quickly tested by injecting some kind of HTML / JavaScript payload. The payload parsing is validated without input. Here is an example of modifying XSS payload's simple "alert" XSS ""

For the practical application of reflective XSS, you may use iframe as a payload in combination with spear phishing. Here's an example of XSS payload that you can use instead of "alert" so now it can load third-party resources with exploit or BeEF hooks provided on the client side.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.