The Burp Suite will now begin logging the requests and responses that pass through the proxy. We have browsed to the DVWA login page and the Burp Suite proxy has captured the request and response:
We are going to use the SQL Injection example in the DVWA for the rest of this tutorial. You can see in the image below that the SQL Injection example is quite simple for us to test:
We need to capture the User ID request after we click the submit button and replace the User ID value with our test inputs. To do this we must ensure that the Burp Suite proxy is configured to intercept our requests:
With the intercept enabled we will submit the User ID request and send it to the intruder as you can see below:
The Burp Suite will send our request to the intruder tool so we can begin our testing. You can see the request in the intruder tool below:
The tool has automatically created payload positions for us. The payload positions are defined using the § character, the intruder will replace the value between two § characters with one of our test inputs. You can modify this behaviour by instructing the Burp Suite to automatically append your input to the original instead of replacing it as we have done in the example above. To instruct the Burp Suite to automatically position its payload markers to append data to your input rather than replace it you need to click on “append to base parameter value”:
The positions tab which is shown in the image above has four different attack types for you to choose from (definitions taken from: ) : Sniper: This uses a single set of payloads. It targets each position in turn, and inserts each payload into that position in turn. Positions which are not targeted during a given request are not affected – the position markers are removed and any text which appears between them in the template remains unchanged. This attack type is useful for testing a number of data fields individually for a common vulnerability (e.g. cross-site scripting). The total number of requests generated in the attack is the product of the number of positions and the number of payloads in the payload set. Battering Ram: This uses a single set of payloads. It iterates through the payloads, and inserts the same payload into all of the defined positions at once. This attack type is useful where an attack requires the same input to be inserted in multiple places within the HTTP request (e.g. a username within the Cookie header and within the message body). The total number of requests generated in the attack is the number of payloads in the payload set. Pitchfork: This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through all payload sets simultaneously, and inserts one payload into each defined position. I.e., the first request will insert the first payload from payload set 1 into position 1 and the first payload from payload set 2 into position 2; the second request will insert the second payload from payload set 1 into position 1 and the second payload from payload set 2 into position 2, etc. This attack type is useful where an attack requires different but related input to be inserted in multiple places within the HTTP request (e.g. a username in one data field, and a known ID number corresponding to that username in another data field). The total number of requests generated by the attack is the number of payloads in the smallest payload set. Cluster Bomb: This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through each payload set in turn, so that all permutations of payload combinations are tested. I.e., if there are two payload positions, the attack will place the first payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2; it will then place the second payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2. This attack type is useful where an attack requires different and unrelated input to be inserted in multiple places within the HTTP request (e.g. a username in one parameter, and an unknown password in another parameter). The total number of requests generated by the attack is the product of the number of payloads in all defined payload sets – this may be extremely large. In this tutorial we are going to use the Sniper attack type to test the User ID field. You can perform a quick search in the positions tab to identify values of interest. We have performed a search below for the word “security”:
|









