Wfuzz: Protect Your Web Application by Finding the Faults In It


Protecting data, especially sensitive information on websites, is extremely essential as users expect their data to be secure. Brute forcing directories, paths, files or even user names and passwords makes Web apps vulnerable. Even the most secure passwords can be hacked, given enough time. The vulnerabilities of Web applications can be protected by using Wfuzz.

Wfuzz is a hacking tool created to launch brute force attacks on Web applications. It can help secure Web applications by finding the vulnerabilities and securing them.

Some of the features of this tool include the capability of multiple injection points with multiple dictionaries; output to HTML, recursion (when carrying out directory brute force attacks), coloured outputs with formatting, etc. Other features include post, headers and authentication data brute forcing, fuzzing cookies, time delays between each request, and SOCK/authentication/proxy support. Wfuzz also allows combining payloads with iterators, HEAD scans, brute force HTTP methods (POST), multiple proxy support (each request through a different proxy) and the hiding of results by return code, word numbers, line numbers, and responses or regex.

This tool is used to brute force Web applications. It can be used to find resources not linked (servlets, directories, scripts, etc), POST parameters for various injections like SQL, LDAP, XSS; form parameters brute-forcing (user name/password), fuzzing and a lot more.

Wfuzz is a free tool which works on the Linux, Windows and MAC OS X operating systems. It can be installed using pip install wfuzz or by cloning the public repository from GitHub and embedding in your own Python package (python install). Wfuzz uses pycurl, pyparsing, JSON, chardet and coloroma.

Wfuzz has been created to facilitate Web app assessment and is based on a simple concept—it replaces any reference to the fuzz keyword by the value of a given payload in the dictionary supplied. A payload in Wfuzz is a source of data.

Basic Wfuzz usage includes fuzzing directories, fuzzing Post requests, fuzzing cookies (using -b in the command), fuzzing custom headers, HTTP verbs, fuzzing proxies and authentication.

Wfuzz contains a wide range of filter switches to use on payloads. This tool also lets us use previous results and combine the payloads by using iterators.

Fuzzing paths and files
This tool is used to retrieve all the paths and files with the single command given below:

wfuzz -w wordlist/general/common.txt

In Wfuzz, -w is used to specify the wordlist used to brute force the directories or files. The file common.txt is downloaded along with Wfuzz; if not cloned from GitHub then the wordlist folder can be separately downloaded. It contains all the dictionaries of common lists, one of which can be chosen while launching a brute force attack. The file specified is followed by the target website’s URL. The website used here is, which is the test and demonstration site for the Acunetix Web vulnerability scanner. The website’s URL, followed by the fuzz keyword, will allow for a large number of requests to be processed.

In this case, it is 949 requests. Every word (payload) along with the response number is displayed. The very beginning of the response and the end are shown in Figures 1 and 2. After this, additional details like the total time, number of processed requests and requests/second are also shown.

Figure 1: Output on fuzzing, part 1
Figure 2: Output on fuzzing, part 2

Fuzzed directories for
The command used is:

wfuzz -w wordlist/general/common.txt –hc 404

The tool’s name, followed by specifying the wordlist, is followed by –hc.

Figure 3: Directories

–hc is used to hide the 404 responses so that not all the failed/false positives on paths and files are shown, such that only existing directories (hidden and open) are displayed. The outputs are admin, images, etc. A few of them can be added to the URL and opened but some (hidden directories) consisting only of encrypted folders/content cannot be opened. As shown, 944 requests have been filtered out of 949.

wfuzz -c -z file,wordlist/general/common_pass.txt –hc 404 -u

This above command is a variation only to find files and it demonstrates different word files.

Here, wfuzz is followed by -c to give an output with colours for readability. Wfuzz has many options to decorate the output. This is followed by -z to specify the payloads for each fuzz keyword. Then comes the file, followed by the path to common_pass.txt, which is a file consisting of common passwords. This is the dictionary used for the brute force attack in this case.

Figure 4: Directories fuzzed using common_pass with colour

–hc is added to eliminate the 404 requests. -u is added to specify the URL for the requests, followed by the URL and the fuzz keyword. The output produced shows admin and “” to be the only files retrieved after brute forcing, as this word list does not contain as many words as the common.txt file.

Using scripts
Wfuzz’s Web application vulnerability scanner is supported by plugins. A script can be active or passive, or both. Scanning mode is indicated by the —script parameter followed by the selected plugins.

Figure 5: Using scripts

Plugins may be selected by category or by name; wildcards can also be used. Default is usually used; in this case, robots are used to parse robots.txt. is the target here.

The command is:

wfuzz --script=robots -z list,robots.txt

Fuzzing post requests
To brute force user names and passwords, fuzz can be used to reveal all payloads in both unknowns.

<wfuzz file>wordlist/others/common_pass.txt -d “uname=FUZZ&pass=FUZZ” --hc 302

The command starts with the keyword and dictionary file. This is followed by -d, which specifies that post data is being fuzzed. In this case, both user name and password are being brute forced so fuzz is mentioned twice, followed by –hc 302 to remove false positives. The URL with .php when fuzzed reveals the user name and passwords. In this case, is fuzzed using common_pass.txt. Fifty-two requests are processed and here, both 302 and 200 responses are shown.

Figure 6: Successful fuzzing with no false positives

A modification
By adding –hc 302, only the successful requests are shown. In this case, the user name and password is ‘test’ and we can log in successfully.

Fuzzing a local host (a website with login page)
The user name and password are brute forced.

<wfuzz -z file>wordlist/others/common_pass.txt -d “uname=FUZZ&pass=FUZZ” --hc 302


The command starts with wfuzz and -z to select the payload and the file, and -d to fetch post data fuzz for user name and password. –hc 302 is added to hide false positives. Instead of the website, localhost is given as input. As the login part is being fuzzed, the URL with .php is given as the target. Fifty-two requests are made in this case, from the file common_pass, as this is the wordlist with the most probability of brute forcing a login page; using this shorter list reduces processing time so it leads to faster results. The list of all valid payloads that will fuzz the user name and password is displayed with 200 responses. The start of the list has been shown in Figure 7.

Figure 7: Localhost login fuzzed, part 1

Fifty-two requests have been processed in 0.16 seconds at a speed of 320 requests per second.

Prevention of brute-forcing
The common strategies used to secure Web applications are:

  • Locking out accounts
  • Limiting failed logins
  • Using captcha
  • Monitoring server logs

Wfuzz uses the given URL and attempts to find the correct combination of user names and passwords from a given file by using all the combinations of words from a specified file against the files/directories/user names that it is attempting to fuzz.

Figure 8: Page not accepting requests

In the example shown above, a minimum of 52 to a maximum of 200,000 requests are being processed by the tool. However complicated the password, it is just a matter of time before the payloads are manipulated enough to crack it. Additionally, the tool is very fast at processing, paving way for greater speed and efficiency. Brute forcing can be done with any combination of letters, numbers and characters.

Figure 9: Post requests processed — 3

A simple but effective way of combating brute forcing and causing Wfuzz to fail while fuzzing can be to limit the number of tries during login, as demonstrated below. As the number of requests is limited, brute forcing as a whole will not be able to proceed more than the set number of limited tries, which is three in this case, allowing the probability of finding the correct user name and corresponding password to decrease substantially. The same has been shown below and explained against localhost.

When a username in the database is entered with the corresponding password correctly, the output is a successful entry.

When the password entered is incorrect more than three times successively, the entry to the Web page is blocked. After three incorrect logins, it doesn’t accept any more requests.

As seen in Figure 8, the page does not allow input of both the user name and password after three failed login attempts. In this way, brute forcing is detected and prevented.
When the command is tried again against localhost:

<wfuzz -z file>wordlist/others/common_pass.txt -d “uname=FUZZ&pass=FUZZ” --hc 302 http://localhost/login.php

Here, the tool returns a pycurl error. Only three attempts were processed, while previously, anywhere from 52 to 946 attempts were processed. Brute forcing as seen earlier cannot be executed as all three attempts have been exhausted and have failed. Additionally, the tool takes only 0.09 seconds to stop processing, after which all three IDs/payloads are returned, as against the time taken above, which ranges from 16.16 to 48.13 seconds.

When fuzzing for paths/directories/files (common fuzzing), the command used is given below:

wfuzz -w wordlist/general/common.txt –hc 404

The number of requests returned is only three and this does not allow for obtaining the user name and password, thus ending in a failure. Similar to fuzzing for post requests, only three requests are processed and it shows a pycurl error.

In conclusion, fuzzing is prevented using a simple but robust method of limiting tries. This article focuses on the ways to use the said application in hacking as well as to prevent brute forcing. Wfuzz is a straightforward application that uses very simple command line inputs to hack Web applications, enabling developers to make their websites secure by finding the faults and vulnerabilities in their application.


Please enter your comment!
Please enter your name here