Although Tamper Data can help with the testing process, sometimes we need a more flexible method to modify requests and more features, such as changing the method used to send them (that is, from GET to POST) or saving the request/response pair for further processing by other tools.
OWASP ZAP is much more than a web proxy, it not only intercepts traffic, it also has lots of features similar to the crawler we used in the previous chapters, vulnerability scanner, fuzzer, brute forcer, and so on. It also has a scripting engine that can be used to automate activities or to create a new functionality.
In this recipe, we will begin the use of OWASP ZAP as a web proxy, intercept a request, and send it to the server after changing some values.
http://192.168.56.102/mutillidae/
.test'
(including the apostrophe) as Name and password'
as Password and click on View Account Details.We get a warning message telling us that some characters in our inputs were invalid. In this case, the apostrophe (') is surely detected and stopped by the application's security measures.
If we check the history in ZAP, we can see that no request was sent with the data we introduced, this is due to a client-side validation mechanism. We will use the proxy interception to bypass this protection.
test
and password
and check the details again.ZAP will steal the focus and a new tab called Break will appear. This is the request we just made on the page, what we can see is a GET
request with the username
and password
parameters sent in the URL. Here, we can add the apostrophes that weren't allowed in the previous attempt.
In this recipe, we used the ZAP proxy to intercept a valid request, modified it to make it invalid or malicious, and then sent it to the server and provoked an unexpected behavior in it.
The first three steps were meant to enable the security protection so that the application can detect the apostrophe as a bad character.
After that we made a test request and verified that some validation was performed. The fact that no request went through the proxy when the alert showed up told us that the validation was performed on the client side, maybe using JavaScript. Upon knowing this, we made a valid request and intercepted it with the proxy, this made us bypass the protection on the client side; we converted that request into a malicious one and sent it to the server; which was unable to process it correctly and returned an error.
13.58.236.191