Learn the code cracker's malicious mindset, so you can find worn-size holes in the software you are designing, testing, and building. Fuzzing for Software Security Testing and Quality Assurance takes a weapon from the black-hat arsenal to give you a powerful new tool to build secure, high-quality software. This practical resource helps you add extra protection without adding expense or time to already tight schedules and budgets. The book shows you how to make fuzzing a standard practice that integrates seamlessly with all development activities.
This comprehensive reference goes through each phase of software development and points out where testing and auditing can tighten security. It surveys all popular commercial fuzzing tools and explains how to select the right one for a software development project. The book also identifies those cases where commercial tools fall short and when there is a need for building your own fuzzing tools.
Review By: David Yu
In this book, the authors present the concept of "fuzzing," an alternative way to find software security bugs. They explain most of the security testing process including vulnerability analysis, QA cycle, metrics, and evaluations. Also provided are examples of source code written in C, Java, assembly language, and even script language of the vulnerable parts. This helps readers understand the common issues and obtain quick functions that can be used in their work.
The authors explain how to crush software by fuzzing, which combines random testing plus negative testing, from my understanding. In the software security testing area, creating a crush on software is important because it exposes security issues like overflow errors. If a program can invoke overflow inside while being attacked from outside, attackers may plug-in the harmful code into the target system. Fuzzing here is more like a specific way of doing pressure, condition verification, or boundary checking.
However, fuzzing is not the only option for security testing. Fuzzing easily exposes crush-down bugs like overflow, but doesn't find functional weakness, such as SQL injections, so quickly. For example, bypass testing is a more efficient way of finding SQL injection issues. For some known issues, if it can be identified as a pattern, scan is better.
Beware that bugs revealed by fuzzing may not be major security issues. For example, crushing down a Web service program is absolutely a security issue, at least a Deny of Service (DoS) problem. But if programmers write the code to isolate each service and protect the instance, it may not be an issue. Bugs need to be judged by testers carefully and not just from the result reported by any testing tool. In verifying security problems reported by third-party tools such as DoS, I've come across "bugs" that are, in fact, normal reactions from the protection part of the software.
This doesn't mean third-party tools for fuzzing are unnecessary. On the contrary, a good fuzzing tool can save testers a lot of time in creating patterns as well as collecting huge numbers of test cases.
For all of these reasons, I would recommend this book to senior software testers or professional security testers. Otherwise, less-experienced professionals may waste time sifting through "learning to use this tool/concept" issues instead of tackling real bugs.