Understanding the insertion points

Burp Scanner is a very efficient scanner, as it targets various insertion points. It targets the input fields, a set of headers, such as cookie, referrer, user agent, and so on. Burp Scanner analyzes the targets individually by sending payloads individually to see how the application handles the payloads. A better understanding to see the insertion points is as follows:

Burp also handles data encoding for various parameters. It understands the parameter in use and any encoding if it follows. Once it detects the encoding, it fuzzes the parameter by fuzzing the payloads by encoding them as shown in the following screenshot. For example, to standard inputs, it passes a normal payload:

For a JSON parameter, it fuzzes with a different payload:

For XML it passes a different payload:

If the application is using a different encoding, such as base64, Burp automatically tries to detect the encoding being used and modifies the payload accordingly:

If the application is using nested encoding, Burp tries to detect this behavior and creates payloads accordingly to help testing for vulnerabilities:

 

Also as we discussed earlier, Burp manipulates the location of the parameters by trying to pass them in different locations as a POST, GET request, adding the values to the headers, and fuzzing them. This is done in an attempt to bypass the web application firewall and to try to send the parameter to the particular application function:

These are all the different styles and mechanisms that Burp follows to help perform scanning over the application. The core question here is, how does it scan and maintain a valid session if additional security is put in place? Well, we have good news; Burp Scanner crawls to every request from the root node and then tests the request depending on the context of the application.

Burp Suite satisfies the following conditions while traversing from node to node:

• Direct testing if there are no tokens, same tokens, or CSRF in cookies
• Traversal from the root node to the request path in case of single CSRF tokens and single-use tokens

The preceding diagram shows the heuristic crawl; if you need to reach a particular request to pentest, there are three other request pages from the root node, Burp will travel through all those pages and reach the target page, just like a simulation of a real-world user. How does this help? Well, this helps in testing tight applications that use a per request CSRF token. Burp is able to figure out the dependencies of the CSRF tokens and perform an efficient scan by traversing to the target request right from the root and taking the CSRF from the response and adding it to the next request, as shown in the following diagram:

You might also wonder how the session handling is managed if the application times out, or the session times out, or even if the session invalidates, right? Burp manages a timeline. It makes a timestamp and validates if the session is still valid. Once it validates, it sets a marker and proceeds with other tests, and then, when it comes to a timeout condition or an invalid session, it goes back to the previous marker and begins the test again, so as to give us an exact accurate pentest result covering all the parameters. The same reference can be understood from the following screenshot:

To sum it up, Scanner does the following things:

• It automatically manages the additional security settings and performs the fuzzing, such as handling the CSRF token types
• It manages encoding and edits the attack payloads accordingly
• It even performs nested fuzzing by double-encoding payloads
• It follows a snapshot-based approach to perform a scan
• It also ensures that parameters are fuzzed from POST to GET, or even pushes them in the headers in an attempt to execute payloads