What Is Fuzzing?

Fuzz testing introduces deliberately malformed inputs into a system with the goal of triggering failures. For example, a fuzz testing solution might supply HTTP headers with random letters in them to see how a web application will respond.

A fuzz testing solution has three elements:

• The “poet” generates the malformed test inputs
• The “courier” delivers the test cases
• The “oracle” checks the target system to see if the fuzzing has caused a failure or other errors

This last process is important, because testers must be able to reproduce a failure using whatever random fuzzing variable caused it in the first place. If they can’t reproduce the error, they can’t fix the underlying problem.

Two main types of fuzz testing predominate: behavioral and coverage-guided. A behavioral fuzz test is designed to show how an application is supposed to function. It tracks the differences between what is expected and what actually happens in the test. Coverage-guided fuzz testing looks at source code for apps at runtime. It probes the source code with random challenges, with the goal of discovering bugs.

Going a layer deeper, application fuzzing tests user interface (UI) features like input fields and buttons. The testing process might involve excessive demand, too-fast actions, or flooding fields with excessive amounts of text or numbers. Protocol fuzzing tests how a server reacts when a protocol introduces bad content. One goal here is to see if protocol requests will be misinterpreted as commands that will be executed on the server. File format fuzzing works with deliberately corrupted files, such as XML, JPG, or DOCX.

Fuzz testing relies on specialized algorithms to generate random or malformed data for input. Algorithms are crafted to maximize code coverage, ensuring that each input variation can trigger unique paths in the application. Two common approaches in fuzzing algorithms are mutation-based fuzzing and generation-based fuzzing. Mutation-based fuzzing alters existing inputs to create variations, while generation-based fuzzing creates inputs from scratch, based on known structures or patterns.

Mutation fuzzing is often simpler and more suitable for black-box testing, where testers have no access to the application’s source code. Generation-based fuzzing is more complex and used for applications with known protocols, providing enhanced effectiveness in testing intricate logic. Both methods contribute to broader application security, uncovering issues that may go unnoticed with traditional testing approaches.

Fuzzing offers QA teams a variety of benefits. For one thing, it’s simple, so fuzzing tends to be easy to scale and is cost effective. The overhead is low, in terms of both time and cost. Once a fuzzing test process is running, it works more or less on its own — without requiring much, if any, human action. It can keep going for an extended period of time.

Simple as it may be, however, fuzzing is often able to detect serious problems and bugs that other testing methods won’t pick up. It’s known for picking up zeroday exploits, for example. Fuzzing delivers a high-level picture of system quality. This is one of the reasons why fuzzing is a popular technique by both ethical and malicious hackers.

Fuzzing has its limitations and challenges. For instance, fuzzing is not very effective at picking up the presence of silent threats that do not cause system crashes or errors. These include worms, Trojans, rootkits, and spyware. Users of open source fuzzers may find the toolset to be somewhat opaque. It can be difficult to know what’s actually happening. Reproducing results tends to be hard at that point.

Fuzzing is not ideal for testing application programming interfaces (APIs). While fuzzing can be useful for probing APIs for problematic responses, such as with overlong queries and code injection, it cannot test for some of the most serious API security weaknesses. For example, fuzzing is not able to determine if an API has been misconfigured, a major source of vulnerability. Nor can fuzzing help with API access control and user authentication.

Instead, proven API testing methodologies and tools are better able to inspect APIs and root out the OWASP Top 10 API vulnerabilities, which fuzzing cannot do. What’s more, API testing processes can reveal “rogue” APIs that operate outside of security controls, as well as “ghost APIs” that have been forgotten and can pose significant risk.

Fuzzing is an essential software and IT system testing method. It can do things that no other type of testing can accomplish. That said, fuzzing has its limitations. As previously mentioned, it is not well suited to “silent” threats or for testing APIs. API testing is better left to practices and toolsets that enable testing of API configurations and detection of known API vulnerabilities, as well as that assess API inventories and track access and authentication.