Fuzzing Web Applications
Hunting for XSS and SQLi effortlessly and automatically
I generally prefer manual hacking when approaching a new web app target. Manual testing is useful for discovering new and unexpected attack vectors, but it also takes up a lot of time and effort.
Automated testing, on the other hand, is much more efficient at teasing out a large number of bugs within a short time frame. In fact, bugs discovered through fuzzing now account for the majority of new CVE entries.
Today, let’s talk a bit about fuzzing web applications, how it is done, and what it can achieve for you.
What is fuzzing?
Fuzzing is a way of finding bugs using automation. It involves providing a wide range of invalid and unexpected data into an application then monitoring the application for exceptions.
The invalid data used to fuzz an application could be crafted for a specific purpose, or randomly generated. The goal is to induce unexpected behavior of an application (like crashes and memory leaks) and see if it leads to an exploitable bug.
In general, fuzzing is particularly useful for exposing bugs like memory leaks, control flow issues, and race conditions.
Fuzzing web applications
There are many different kinds of fuzzing, each optimized for testing a specific type of application. Web application fuzzing is the field of fuzzing web applications to expose common web vulnerabilities, like injection issues, XSS, and more.
Fuzzing versus static analysis
So, your question now might be: why not just do static analysis on the source code? What are the advantages of fuzzing an application versus simply diving into the code?
I am a huge proponent of doing static code analysis to find bugs. Here’s an intro to get you started reviewing code for security purposes:
Static code analysis is an invaluable tool to identify bugs and improper programming practices that can be exploited by attackers. However, static analysis has its limitations.
First, it only evaluates an application in a non-live state. Performing code review on an application won’t let you simulate how the application will react when it’s running live and clients are interacting with it. It is very difficult to take into account all the possible malicious inputs an attacker can provide when doing static analysis.
Static code analysis also requires access to the source code of an application. When doing a black-box test and you are not able to obtain the source code, fuzzing is a great way of increasing test coverage since source code is not needed when fuzzing an application.
Steps of fuzzing a web application
Let’s go through the steps that you must take while fuzzing a web app!
- Determine the data entry points
The first thing to do when fuzzing a web application is to identify the ways a client can provide input to the application. What are the endpoints that take input? What are the parameters used? What headers do the application use?
2. Decide on the payload list
After you’ve identified the data entry points, you’d have to determine what data to feed to the application. For web applications, the most useful fuzzing data would be lists of known XSS payloads, SQLi payloads, and so on. I recommend downloading SecLists here for a pretty comprehensive payload list for fuzzing web applications:
SecList is pretty good for detecting already known vulnerabilities. Another way of fuzzing is to generate payloads randomly, including payloads like the below to try to induce errors in the web app:
- Payloads that are really long,
- payloads that contain odd characters of various encodings,
- and payloads that contain certain special characters, like the new line character, the line feed character, and more.
By feeding the application garbage data like this, you might be able to detect unexpected behavior and discover new classes of vulnerabilities!
3. Fuzz
Now, all there is to do is to systematically feed your fuzz payload list to the data entry points of the application! There are several ways of doing it, depending on your needs and your programming skills.
Burp Intruder
The first way to automate fuzzing is to use the BurpSuite intruder. Burp provides a GUI for configuring your fuzzer settings, so you can basically choose an endpoint, choose a payload list and start fuzzing!
With Burp Intruder, you can specify where the payloads should go in a request, which data parameters to insert into, and how many different positions to insert the payloads at once.
You can also select a predefined list of payloads or generate payload lists within burp.
The downside to using Burp is that the community version limits the functionality of the fuzzer, and time throttles its attacks. So it would be a lot less efficient than a non-time-throttled fuzzer. So unless you have the professional version, I would recommend simply implementing your own fuzzer with a programming language of your choice, or to use the OWASP ZAP fuzzer.
OWASP ZAP Fuzzer
The OWASP Zed Attack Proxy (ZAP) also has a built-in fuzzer that you can use. Unlike the Burp intruder, it is not time-throttled and all functionalities are free.
But just like the Burp Intruder, with these pre-built fuzzers, it is sometimes difficult to have all the functionalities that you need. So, feel free to try writing your own fuzzer.
4. Monitor the results
The final step is to analyze the results your fuzzer returned. You should look for patterns and anomalies from the server response. What you should be looking for will depend on the payload set that you use. For example, when fuzzing for SQLi, you might want to look for a change in content length or response time. And when searching for path traversals, you might look for special keywords in the response. Looking more into each vulnerability type will help you identify the key signatures of each vulnerability being present.
Pitfalls of fuzzing
Of course, fuzzing is not the magic cure-all solution for all bug detection. There are certain limitations to using fuzzing to hack web applications.
One of these limitations is rate-limiting by the server. During a remote, black-box engagement, you might not be able to send in large numbers of payloads to the application without being detected by the server or hitting some kind of rate-limit. This can cause testing to slow down or even cause you to be banned from the service.
When fuzzing during black-box testing, it is also difficult to accurately evaluate the impact of the bug since you do not have access to the code and you are getting a very limited sample of the application’s behavior. This means that further manual testing is often needed to classify the bug’s validity and significance.
Think of fuzzing as a metal detector: it merely points you to the suspicious spots. And in the end, you need to inspect more closely to see if you have found something of value.
Another limitation is the classes of bugs that fuzzing a web application can find. Although fuzzing is good at finding certain simplistic vulnerabilities like XSS and SQLi, and can sometimes aid in the discovery of new bug types, it is not much help in detecting business logic errors, and bugs that require multiple steps to exploit. These complex bugs are a big source of potential attacks and still need to be teased out manually. This is why fuzzing should be an essential part of your testing process, but it should by no means be the only part of it.
Is there anything I missed? Feel free to let me know on Twitter.
Thanks for reading. And remember: trying this on systems where you don’t have permission to test is illegal. If you’ve found a vulnerability, please disclose it responsibly to the vendor. Help make our Internet a safer place.
