What is Fuzzing?

There’s a reason the pitcher in a baseball game starts the windup with the ball hidden behind his or her back. The batter is not supposed to know what kind of pitch is coming. The better the deception, the better the chance of a strike. That is the logic behind fuzzing, an approach to quality assurance (QA) that attempts to trigger errors in a system (or crash it altogether) by delivering a large quantity of random inputs.

Like the batter who is expecting a fastball, but instead gets a slider, the target system may not know how to respond—and that’s the whole point. Standard testing methods cover the predictable. Fuzzing is all about blasting a target system with unpredictable inputs. Done right, it can help detect coding errors in software, along with security vulnerabilities in applications, networks, and operating systems. A fuzzing system can find vulnerabilities to threats like buffer overflow, cross-site scripting (XSS), denial of service (DoS), and code injection.

The term “fuzz” was coined by Professor Barton Miller at the University of Wisconsin in the eighties. He’d been trying to log into a UNIX system using a dial-up network. Interference from a storm caused the system to crash. Professor Miller got the idea of simulating the interference to see how well systems could respond.

How does fuzzing work?

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 fuzzer, as these testing solutions are known, comprises three elements:

• The “poet”—which generates the malform test inputs
• The “courier”—which delivers the test cases
• The “oracle”—which 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 cannot reproduce the error, they can’t fix the underlying problem.

Types of fuzzing

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, JPEG, or .docx.

Benefits of fuzzing

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 actions. 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 “Zero Day” 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 white- and black-hat hackers.

Challenges of fuzzing

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

Why API Security testing is superior

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 assess API inventories and track access and authentication.