1

I am testing an API and one parameter is vulnerable to SQL injection. When I run OWASP ZAP's fuzzer on this parameter, the input "; or 1=1" results in a successful exploit of SQL injection. However, manually supplying this input results in an Oracle error code and the exploit is not successful.

Is it the case then that fuzzers can result in successful exploits for certain inputs that manual testing cannot? I am trying to understand more about fuzzers and it seems to me that fuzzers can generate certain conditions that manual testing can't generate. Is this correct? If so, why?

  • 3
    A fuzzer is nothing magic and everything which the fuzzer does can be reproduced if you do the exactly same thing as the fuzzer manually. My guess is that you fail in doing exactly the same but giving the information is impossible to say were exactly your error is. When in doubt look at the HTTP request generated by the fuzzer and compare it to the HTTP requested generated by you. – Steffen Ullrich May 10 '16 at 8:13
  • False positive? Or not an exact reproduction of the exploit (properly url encoded)? – Bob Ortiz May 10 '16 at 8:42
  • @dwarf015 I don't think it is a false positive because manually if you provide an input like a single quote, you get an Oracle DB error message. – Earthling May 10 '16 at 8:58
  • I once had a similar trouble with an XSS vulnerability which did not work in browsers (due to url encoding reasons) but worked in burp suite. However, as soon as you can exploit a SQL vulnerability with one tool, it can be considered critical. – Lukas May 10 '16 at 9:05
3

[I]t seems to me that fuzzers can generate certain conditions that manual testing can't generate.

No, they can't. The server does not know if an HTTP request originates from a fuzzer like ZAP, a browser or anything else as long as they send exactly the same HTTP request.

The key words here are exactly the same. Since you don't know what is going on on the server, anything could possibly affect the result. Look at the HTTP request you send from ZAP (see demo), and look at the HTTP request you send manually. If you are using a browser for the manual testing, just use the developer tools to see it. An alternative approach is to use a program like WireShark to inspect the requests.

When you got the two requests in front of you, compare them. Where is the difference? That is probably the solution to this mystery.

An alternative explanation would be random behaviour on the server, or a change of behavior because the exploit was fixed. Repeated testing could rule out those.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.