Warm and Fuzzy


The opposite scenario, however, can be a problem as well. Suppose that our fuzzer is aware of the checksum and then modifies its fuzzed output data files so that the checksum is always valid. What happens now if there is a defect or security vulnerability in the checksum logic? This logic isn't being tested, as the fuzzer has implicitly assumed that it's always correct; this is an assumption that may not be valid. To put it in higher-level terms, by giving the fuzzer knowledge of the expected input, you're telling it to create input in the way that the program expects to receive it. The whole point of fuzzing, though, is to test the program by giving it unexpected input. This is the classic debate between "dumb" fuzzers that have no knowledge of the expected input format and "smart" fuzzers that do. The reality is that neither type is sufficient on its own and to achieve the best results, both types of fuzzers should be used to test the application.

If you haven't started already, I strongly suggest that you make fuzz testing part of your testing process. The material presented here doesn't even scratch the surface of the power and possibilities of fuzzing. If you're interested in learning more, I recommend reviewing the book Fuzzing: Brute Force Vulnerability Discovery by Michael Sutton, Adam Greene, and Pedram Amini.

About the author

Bryan Sullivan's picture Bryan Sullivan

Bryan Sullivan is a security program manager on the Security Development Lifecycle (SDL) team at Microsoft. He is a frequent speaker at industry events, including Black Hat, BlueHat, and RSA Conference. Bryan is also a published author on Web application security topics. His first book, Ajax Security was published by Addison-Wesley in 2007.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!