Web Fuzzing

 

                                       Introduction

Web fuzzing is a critical technique in web application security to identify vulnerabilities by testing various inputs. It involves automated testing of web applications by providing unexpected or random data to detect potential flaws that attackers could exploit. In the world of web application security, the terms "fuzzing" and "brute-forcing" are often used interchangeably, and for beginners, it's perfectly fine to consider them as similar techniques. However, there are some subtle distinctions between the two. Imagine you're trying to open a locked door. Fuzzing would be like throwing everything you can find at the door - keys, screwdrivers, even a rubber duck - to see if anything unlocks it. Brute-forcing would be like trying every combination on a key ring until you find the one that opens the door. 

Why Fuzz Web Applications?

Web applications have become the backbone of modern businesses and communication, handling vast amounts of sensitive data and enabling critical online interactions. However, their complexity and interconnectedness also make them prime targets for cyberattacks. Manual testing, while essential, can only go so far in identifying vulnerabilities. Here's where web fuzzing shines:

• Uncovering Hidden Vulnerabilities: Fuzzing can uncover vulnerabilities that traditional security testing methods might miss.
• Automating Security Testing: Fuzzing automates generating and sending test inputs, saving valuable time and resources.
• Simulating Real-World Attacks: Fuzzers can mimic attackers' techniques, helping you identify weaknesses before malicious actors exploit them. This proactive approach can significantly reduce the risk of a successful attack.
• Strengthening Input Validation: Fuzzing helps identify weaknesses in input validation mechanisms, which are crucial for preventing common vulnerabilities like SQL injection and cross-site scripting (XSS).
• Improving Code Quality: Fuzzing improves overall code quality by uncovering bugs and errors. Developers can use the feedback from fuzzing to write more robust and secure code.
• Continuous Security: Fuzzing can be integrated into the software development lifecycle (SDLC) as part of continuous integration and continuous deployment (CI/CD) pipelines, ensuring that security testing is performed regularly and vulnerabilities are caught early in the development process.

Before we dive into the practical aspects of web fuzzing, it's important to understand some key concepts:

Concept	Description	Example
Wordlist	A dictionary or list of words, phrases, file names, directory names, or parameter values used as input during fuzzing.	Generic: admin, login, password, backup, config Application-specific: productID, addToCart, checkout
Payload	The actual data sent to the web application during fuzzing. Can be a simple string, numerical value, or complex data structure.	' OR 1=1 -- (for SQL injection)
Response Analysis	Examining the web application's responses (e.g., response codes, error messages) to the fuzzer's payloads to identify anomalies that might indicate vulnerabilities.	Normal: 200 OK Error (potential SQLi): 500 Internal Server Error with a database error message
Fuzzer	A software tool that automates generating and sending payloads to a web application and analyzing the responses.	ffuf, wfuzz, Burp Suite Intruder
False Positive	A result that is incorrectly identified as a vulnerability by the fuzzer.	A 404 Not Found error for a non-existent directory.
False Negative	A vulnerability that exists in the web application but is not detected by the fuzzer.	A subtle logic flaw in a payment processing function.
Fuzzing Scope	The specific parts of the web application that you are targeting with your fuzzing efforts.	Only fuzzing the login page or focusing on a particular API endpoint.

we will utilize four powerful tools designed for web application reconnaissance and vulnerability assessment. To streamline our setup, we'll install them all upfront. this tools are Ffuf, gobuster, FeroxBuster, WebFuzzForge. let's see which tools can do which type of work.

                                                                         FFuf

Use Case	Description
Directory and File Enumeration	Quickly identify hidden directories and files on a web server.
Parameter Discovery	Find and test parameters within web applications.
Brute-Force Attack	Perform brute-force attacks to discover login credentials or other sensitive information.

                                                                       gobuster

Use Case	Description
Content Discovery	Quickly scan and find hidden web content such as directories, files, and virtual hosts.
DNS Subdomain Enumeration	Identify subdomains of a target domain.
WordPress Content Detection	Use specific wordlists to find WordPress-related content.

                              FeroxBuster

Use Case	Description
Recursive Scanning	Perform recursive scans to discover nested directories and files.
Unlinked Content Discovery	Identify content that is not linked within the web application.
High-Performance Scans	Benefit from Rust's performance to conduct high-speed content discovery.

                                                                  wfuzz/wenum

Use Case	Description
Directory and File Enumeration	Quickly identify hidden directories and files on a web server.
Parameter Discovery	Find and test parameters within web applications.
Brute-Force Attack	Perform brute-force attacks to discover login credentials or other sensitive information

                                                 Directory and File Fuzzing

Web applications often have directories and files that are not directly linked or visible to users. These hidden resources may contain sensitive information, backup files, configuration files, or even old, vulnerable application versions. Directory and file fuzzing aims to uncover these hidden assets, providing attackers with potential entry points or valuable information for further exploitation. Web applications often house a treasure trove of hidden resources — directories, files, and endpoints that aren't readily accessible through the main interface. These concealed areas might hold valuable information for attackers, including:

• Sensitive data: Backup files, configuration settings, or logs containing user credentials or other confidential information.
• Outdated content: Older versions of files or scripts that may be vulnerable to known exploits.
• Development resources: Test environments, staging sites, or administrative panels that could be leveraged for further attacks.
• Hidden functionalities: Undocumented features or endpoints that could expose unexpected vulnerabilities.

Wordlists are the lifeblood of directory and file fuzzing. They provide the potential directory and file names your chosen tool will use to probe the web application. Effective wordlists can significantly increase your chances of discovering hidden assets. One of the most comprehensive and widely-used collections of wordlists is SecLists. This open-source project on GitHub (https://github.com/danielmiessler/SecLists) provides a vast repository of wordlists for various security testing purposes, including directory and file fuzzing. SecLists contains wordlists for:

• Common directory and file names
• Backup files
• Configuration files
• Vulnerable scripts
• And much more

Now that you understand the concept of wordlists, let's dive into the fuzzing process. We'll use ffuf, a powerful and flexible fuzzing tool, to uncover hidden directories and files on our target web application. 

ffuf

We will use ffuf for this fuzzing task. Here's how ffuf generally works:

1. Wordlist: You provide ffuf with a wordlist containing potential directory or file names.
2. URL with FUZZ keyword: You construct a URL with the FUZZ keyword as a placeholder where the wordlist entries will be inserted.
3. Requests: ffuf iterates through the wordlist, replacing the FUZZ keyword in the URL with each entry and sending HTTP requests to the target web server.
4. Response Analysis: ffuf analyzes the server's responses (status codes, content length, etc.) and filters the results based on your criteria.

Directory Fuzzing

The first step is to perform directory fuzzing, which helps us discover hidden directories on the web server. Here's the ffuf command we'll use:

• -w (wordlist): Specifies the path to the wordlist we want to use. In this case, we're using a medium-sized directory list from SecLists.
• -u (URL): Specifies the base URL to fuzz. The FUZZ keyword acts as a placeholder where the fuzzer will insert words from the wordlist. 

This defines which HTTP status codes ffuf is treating as valid "hits." Notably:

• 200–299: Successful responses  means it exists and is accessible
• 301, 302: Redirects
• 403, 401: Forbidden or unauthorized access (can still indicate a valid path!)
• 500: Server errors (possibly exploitable)

File Fuzzing

While directory fuzzing focuses on finding folders, file fuzzing dives deeper into discovering specific files within those directories or even in the root of the web application. Web applications use various file types to serve content and perform different functions. Some common file extensions include:

• .php: Files containing PHP code, a popular server-side scripting language.
• .html: Files that define the structure and content of web pages.
• .txt: Plain text files, often storing simple information or logs.
• .bak: Backup files are created to preserve previous versions of files in case of errors or modifications.
• .js: Files containing JavaScript code add interactivity and dynamic functionality to web pages.

By fuzzing for these common extensions with a wordlist of common file names, we increase our chances of discovering files that might be unintentionally exposed or misconfigured, potentially leading to information disclosure or other vulnerabilities.  

                                                        Recursive Fuzzing

Recursive fuzzing means ffuf doesn’t stop after finding a valid directory or file—it goes deeper. So far, we've focused on fuzzing directories directly under the web root and files within a single directory. Manually fuzzing each level would be tedious and time-consuming. This is where recursive fuzzing comes in handy. Recursive fuzzing is an automated way to delve into the depths of a web application's directory structure. It's a pretty basic 3 step process: 

1. Initial Fuzzing:
   • The fuzzing process begins with the top-level directory, typically the web root (/).
   • The fuzzer starts sending requests based on the provided wordlist containing the potential directory and file names.
   • The fuzzer analyzes server responses, looking for successful results (e.g., HTTP 200 OK) that indicate the existence of a directory.
2. Directory Discovery and Expansion:
   • When a valid directory is found, the fuzzer doesn't just note it down. It creates a new branch for that directory, essentially appending the directory name to the base URL.
   • For example, if the fuzzer finds a directory named admin at the root level, it will create a new branch like http://localhost/admin/.
   • This new branch becomes the starting point for a fresh fuzzing process. The fuzzer will again iterate through the wordlist, appending each entry to the new branch's URL (e.g., http://localhost/admin/FUZZ).
3. Iterative Depth:
• The process repeats for each discovered directory, creating further branches and expanding the fuzzing scope deeper into the web application's structure.
• This continues until a specified depth limit is reached (e.g., a maximum of three levels deep) or no more valid directories are found.

Imagine a tree structure where the web root is the trunk, and each discovered directory is a branch. Recursive fuzzing systematically explores each branch, going deeper and deeper until it reaches the leaves (files) or encounters a predetermined stopping point. 

 the ffuf -ic option proves invaluable. By enabling this option, ffuf intelligently ignores commented lines during fuzzing, preventing them from being treated as valid inputs. As ffuf recursively explores level1, it uncovers two additional directories: level2 and level3. Each is added to the fuzzing queue, expanding the search depth.

Be Responsible

While recursive fuzzing is a powerful technique, it can also be resource-intensive, especially on large web applications. Excessive requests can overwhelm the target server, potentially causing performance issues or triggering security mechanisms.

To mitigate these risks, ffuf provides options for fine-tuning the recursive fuzzing process:

• -recursion-depth: This flag allows you to set a maximum depth for recursive exploration. For example, -recursion-depth 2 limits fuzzing to two levels deep (the starting directory and its immediate subdirectories).
• -rate: You can control the rate at which ffuf sends requests per second, preventing the server from being overloaded.
• -timeout: This option sets the timeout for individual requests, helping to prevent the fuzzer from hanging on unresponsive targets.

EX: -recursion -recursion-depth 2 -rate 500

                                                 Parameter and Value Fuzzing

Building upon the discovery of hidden directories and files, we now delve into parameter and value fuzzing. This technique focuses on manipulating the parameters and their values within web requests to uncover vulnerabilities in how the application processes input. You'll often spot GET parameters right in the URL, following a question mark (?). Multiple parameters are strung together using ampersands (&). like: https://www.stonehelm.co.uk/browser.php?genre=contact+stonehelm&headerType=spc&file=contact.php . In this URL:

• typ is a parameter with the value "spc"
• file is another parameter with the value "contact.php"

GET parameters are like postcards – their information is visible to anyone who glances at the URL.  While GET parameters are like open postcards, POST parameters are more like sealed envelopes, carrying their information discreetly within the body of the HTTP request. They are not visible directly in the URL, making them the preferred method for transmitting sensitive data like login credentials, personal information, or financial details. 

Why Parameters Matter for Fuzzing

Parameters are the gateways through which you can interact with a web application. By manipulating their values, you can test how the application responds to different inputs, potentially uncovering vulnerabilities. For instance:

• Altering a product ID in a shopping cart URL could reveal pricing errors or unauthorized access to other users' orders.
• Modifying a hidden parameter in a request might unlock hidden features or administrative functions.
• Injecting malicious code into a search query could expose vulnerabilities like Cross-Site Scripting (XSS) or SQL Injection (SQLi).

In this section, we'll leverage wenum to explore both GET and POST parameters within our target web application, ultimately aiming to uncover hidden values that trigger unique responses, potentially revealing vulnerabilities. 

                                        Virtual Host and Subdomain Fuzzing

Both virtual hosting (vhosting) and subdomains play pivotal roles in organizing and managing web content. Virtual hosting enables multiple websites or domains to be served from a single server or IP address. Each vhost is associated with a unique domain name or hostname. When a client sends an HTTP request, the web server examines the Host header to determine which vhost's content to deliver. Subdomains, on the other hand, are extensions of a primary domain name, creating a hierarchical structure within the domain. Let's dissect the Gobuster vhost fuzzing. gobuster is primarily known for directory and file enumeration, its capabilities extend to virtual host (vhost) discovery, making it a valuable tool in assessing the security posture of a web server. Let's dissect the Gobuster vhost fuzzing command:

gobuster vhost: This flag activates Gobuster's vhost fuzzing mode, instructing it to focus on discovering virtual hosts rather than directories or files. 

--append-domain: This crucial flag instructs Gobuster to append the base domain (inlanefreight.htb) to each word in the wordlist. This ensures that the Host header in each request includes a complete domain name (e.g., admin.inlanefreight.htb), which is essential for vhost discovery. 

now for subdomain. the process is same but here will be use :

gobuster dns: Activates Gobuster's DNS fuzzing mode, directing it to focus on discovering subdomains.

-d website name: Specifies the target domain (e.g., inlanefreight.com) for which you want to discover subdomains.

                                                  Filtering Fuzzing Output

Web fuzzing tools like gobuster, ffuf, and wfuzz are designed to perform comprehensive scans, often generating a vast amount of data. Sifting through this output to identify the most relevant findings can be a daunting task. However, these tools offer powerful filtering mechanisms to streamline your analysis and focus on the results that matter most. Filtering code of the tools are:

                                                          Gobuster

Gobuster offers various filtering options depending on the module being run, to help you focus on specific responses and streamline your analysis. There is a small caveat, the -s and -b options are only available in the dir fuzzing mode.

Flag	Description	Example Scenario
-s (include)	Include only responses with the specified status codes (comma-separated).	You're looking for redirects, so you filter for codes 301,302,307
-b (exclude)	Exclude responses with the specified status codes (comma-separated).	The server returns many 404 errors. Exclude them with -b 404
--exclude-length	Exclude responses with specific content lengths (comma-separated, supports ranges).	You're not interested in 0-byte or 404-byte responses, so use --exclude-length 0,404

By strategically combining these filtering options, you can tailor Gobuster's output to your specific needs and focus on the most relevant results for your security assessments.

                                               FFUF

FFUF offers a highly customizable filtering system, enabling precise control over the displayed output. This allows you to efficiently sift through potentially large amounts of data and focus on the most relevant findings. FFUF's filtering options are categorized into multiple types, each serving a specific purpose in refining your results.

Flag	Description	Example Scenario
-mc (match code)	Include only responses that match the specified status codes. You can provide a single code, multiple codes separated by commas, or ranges of codes separated by hyphens (e.g., 200,204,301, 400-499). The default behavior is to match codes 200-299, 301, 302, 307, 401, 403, 405, and 500.	After fuzzing, you notice many 302 (Found) redirects, but you're primarily interested in 200 (OK) responses. Use -mc 200 to isolate these.
-fc (filter code)	Exclude responses that match the specified status codes, using the same format as -mc. This is useful for removing common error codes like 404 Not Found.	A scan returns many 404 errors. Use -fc 404 to remove them from the output.
-fs (filter size)	Exclude responses with a specific size or range of sizes. You can specify single sizes or ranges using hyphens (e.g., -fs 0 for empty responses, -fs 100-200 for responses between 100 and 200 bytes).	You suspect the interesting responses will be larger than 1KB. Use -fs 0-1023 to filter out smaller responses.
-ms (match size)	Include only responses that match a specific size or range of sizes, using the same format as -fs.	You are looking for a backup file that you know is exactly 3456 bytes in size. Use -ms 3456 to find it.
-fw (filter out number of words in response)	Exclude responses containing the specified number of words in the response.	You're filtering out a specific number of words from the responses. Use -fw 219 to filter for responses containing that amount of words.
-mw (match word count)	Include only responses that have the specified amount of words in the response body.	You're looking for short, specific error messages. Use -mw 5-10 to filter for responses with 5 to 10 words.
-fl (filter line)	Exclude responses with a specific number of lines or range of lines. For example, -fl 5 will filter out responses with 5 lines.	You notice a pattern of 10-line error messages. Use -fl 10 to filter them out.
-ml (match line count)	Include only responses that have the specified amount of lines in the response body.	You're looking for responses with a specific format, such as 20 lines. Use -ml 20 to isolate them.
-mt (match time)	Include only responses that meet a specific time-to-first-byte (TTFB) condition. This is useful for identifying responses that are unusually slow or fast, potentially indicating interesting behavior.	The application responds slowly when processing certain inputs. Use -mt >500 to find responses with a TTFB greater than 500 milliseconds.

                                             Feroxbuster

Feroxbuster's filtering system is designed to be both powerful and flexible, enabling you to fine-tune the results you receive during a scan. It offers a variety of filters that operate on both the request and response levels.

Flag	Description	Example Scenario
--dont-scan (Request)	Exclude specific URLs or patterns from being scanned (even if found in links during recursion).	You know the /uploads directory contains only images, so you can exclude it using --dont-scan /uploads.
-S, --filter-size	Exclude responses based on their size (in bytes). You can specify single sizes or comma-separated ranges.	You've noticed many 1KB error pages. Use -S 1024 to exclude them.
-X, --filter-regex	Exclude responses whose body or headers match the specified regular expression.	Filter out pages with a specific error message using -X "Access Denied".
-W, --filter-words	Exclude responses with a specific word count or range of word counts.	Eliminate responses with very few words (e.g., error messages) using -W 0-10.
-N, --filter-lines	Exclude responses with a specific line count or range of line counts.	Filter out long, verbose pages with -N 50-.
-C, --filter-status	Exclude responses based on specific HTTP status codes. This operates as a denylist.	Suppress common error codes like 404 and 500 using -C 404,500.
--filter-similar-to	Exclude responses that are similar to a given webpage.	Remove duplicate or near-duplicate pages based on a reference page using --filter-similar-to error.html.
-s, --status-codes	Include only responses with the specified status codes. This operates as an allowlist (default: all).	Focus on successful responses using -s 200,204,301,302.

                                                      Validating Findings

Fuzzing is excellent at casting a wide net and generating potential leads, but not every finding is a genuine vulnerability. The process often yields false positives – harmless anomalies that trigger the fuzzer's detection mechanisms but pose no real threat. This is why validation is a crucial step in the fuzzing workflow. Validating findings serves several important purposes:

• Confirming Vulnerabilities: Ensures that the discovered issues are real vulnerabilities and not just false alarms.
• Understanding Impact: Helps you assess the severity of the vulnerability and the potential impact on the web application.
• Reproducing the Issue: Provides a way to consistently replicate the vulnerability, aiding in developing a fix or mitigation strategy.
• Gather Evidence: Collect proof of the vulnerability to share with developers or stakeholders.

Backup files are designed to preserve data, which means they might include:

• Database dumps: These files could contain entire databases, including user credentials, personal information, and other confidential data.
• Configuration files: These files might store API keys, encryption keys, or other sensitive settings that attackers could exploit.
• Source code: Backup copies of source code could reveal vulnerabilities or implementation details that attackers could leverage.

If an attacker gains access to these files, they could potentially compromise the entire web application, steal sensitive data, or cause significant damage. First, we need to confirm if this directory is truly browsable. We can use curl to validate if it is or isn't. 

curl http://vulnerableweb.com/backup/

Examine the output in your terminal. If the server responds with a list of files and directories contained within the /backup directory, you've successfully confirmed the directory listing vulnerability. 

 To responsibly confirm the vulnerability without risking exposure of sensitive data, the optimal approach is to examine the response headers for clues about the files within the directory. Specifically, the Content-Type header often indicates the type of file (e.g., application/sql for a database dump, application/zip for a compressed backup). Additionally, scrutinize the Content-Length header. A value greater than zero suggests a file with actual content, whereas a zero-length file, while potentially unusual, may not pose a direct vulnerability.

                                               Web APIs

A Web API, or Web Application Programming Interface, is a set of rules and specifications that enable different software applications to communicate over the web. a Web API serves as a bridge between a server. There are various Web APIs, each with strengths and use cases. like: 

REST APIs: REST APIs are a popular architectural style for building web services. They use a stateless, client-server communication model where clients send requests to servers to access or manipulate resources. REST APIs utilize standard HTTP methods (GET, POST, PUT, DELETE) to perform CRUD (Create, Read, Update, Delete) operations on resources identified by unique URLs.

SOAP APIs, :SOAP APIs follow a more formal and standardized protocol for exchanging structured information. They use XML to define messages, which are then encapsulated in SOAP envelopes and transmitted over network protocols like HTTP or SMTP. SOAP APIs often include built-in security, reliability, and transaction management features, making them suitable for enterprise-level applications requiring strict data integrity and error handling.

How APIs are different from a web server

While both traditional web pages and Web APIs play vital roles in the web ecosystem, they have distinct structure, communication, and functionality characteristics. Understanding these differences is crucial for effective fuzzing.

Feature	Web Server	API (Application Programming Interface)
Purpose	Primarily designed to serve static content (HTML, CSS, images) and dynamic web pages (generated by server-side scripts).	Primarily designed to provide a way for different software applications to communicate with each other, exchange data, and trigger actions.
Communication	Communicates with web browsers using the HTTP (Hypertext Transfer Protocol).	Can use various protocols for communication, including HTTP, HTTPS, SOAP, and others, depending on the specific API.
Data Format	Primarily deals with HTML, CSS, JavaScript, and other web-related formats.	Can exchange data in various formats, including JSON, XML, and others, depending on the API specification.
User Interaction	Users interact with web servers directly through web browsers to view web pages and content.	Users typically do not interact with APIs directly; instead, applications use APIs to access data or functionality on behalf of the user.
Access	Web servers are usually publicly accessible over the internet.	APIs can be publicly accessible, private (for internal use only), or partner (accessible to specific partners or clients).
Example	When you access a website like https://www.example.com, you are interacting with a web server that sends you the HTML, CSS, and JavaScript code to render the web page in your browser.	A weather app on your phone might use a weather API to fetch weather data from a remote server. The app then processes this data and displays it to you in a user-friendly format. You are not directly interacting with the API, but the app is using it behind the scenes to provide you with the weather information.

                                                       Identifying Endpoints

You must know where to look before you can start fuzzing Web APIs. Identifying the endpoints that the API exposes is the first crucial step in this process. 

REST APIs are built around the concept of resources, which are identified by unique URLs called endpoints.

Fuzzing the API

We will use a fuzzer that will use a wordlist in an attempt to discover these undocumented endpoints. Run the commands to pull, install the requirements, and run the fuzzer: