Fuzzing, or fuzz testing, isn't actually a new technique. It was developed back in 1989 at the University of Wisconsin-Madison by Professor Barton Miller. With today's focus on developing more secure software, fuzzing has become a more widely used and acknowledged code-testing method.
During the fuzzing process, a program is bombarded with random data, called fuzz. If the program fails to cope with any of this data and begins to crash, lock up, consume memory or produce uncontrolled errors, the developer knows that there is a flaw somewhere within the code. The flaw can then be located and rectified before the program is released or deployed, thus keeping a possible vulnerability out of the final release version. Fuzzing has been frequently used to uncover buffer overflows, which occur when the number of input characters exceeds the available buffer space.
Software programs have several input possibilities, like mice, keyboards and screen devices. Other inputs include calls from other programs or controllers embedded in the actual system. Fuzzing effectively finds bugs because the data entered into a program is random and therefore not constrained by any preconceptions about how the software should behave. When people test software themselves, they may make assumptions about how the software will be used, causing certain input permutations to be overlooked.
A thorough fuzz test uses a combination of valid test data and random fuzz data. The valid data prevents an application from rejecting the information before it can reach a defective piece of code.
You must be aware, though, that passing a fuzz test doesn't make a program bug-free. Fuzzing only allows the simulation of a random, limited sample of a program's behavior. The tests may only show that the software can handle exceptions without crashing. Also, fuzzing doesn't test for logical flaws that can be exploited.
A big advantage of fuzz testing is its cost effectiveness; the testing is usually automated and easy to set up. It is a useful testing method, but it should be used as one of several software-testing methods. Static analysis, peer review and secure coding methodologies should all be a part of any secure software development process.
Dig deeper on Vulnerability Risk Assessment
Related Q&A from Michael Cobb
Expert Michael Cobb explains how password change frequency and reuse for third-party apps should be addressed in enterprise password policies.continue reading
Learn how a Web-based free spam-filtering service can secure email and prevent spam from attacking your enterprise.continue reading
Do you know some of the best third-party patch deployment tools? See expert Michael Cobb's recommendations on which tools would work best for your ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.