The concept of fuzzing has been around for almost two decades but has only recently captured widespread attention. In 2006, we saw a plague of new vulnerabilities emerge that affected popular client-side applications including Microsoft Internet Explorer, Microsoft Word and Microsoft Excel; a large portion of these vulnerabilities were discovered through fuzzing. As a result of fuzzing being used so successfully on these mainstream products, it has received a resurgence of attention from the security community. The sheer fact that this is the first published book dedicated to the subject matter is an additional indicator that there is an increasing interest in fuzzing.
Having been involved in the vulnerability research community for years, we have used a variety of fuzzing technologies in our day to day work, ranging from hobby projects to high end commercial products. Each of the authors has been involved in the development of both privately held and publicly released fuzzers. We leveraged our combined experience and ongoing research projects to compose this bleeding edge book, which we hope you will find useful.
We strongly believe that the quantity and severity of vulnerabilities will continue to grow so long as security is deemed to be the sole responsibility of a security team. As such, we have taken strong efforts to write for a larger audience than just security researchers, including both readers who are new to fuzzing and those who have already had significant experience.
It is unrealistic to believe that secure applications can emerge from the development process if development organizations simply hand completed applications to a security team for a quick audit prior to production launch. Gone are the days when a developer or a member of the QA Team can say, "security's not my problem – we have a security team that worries about that". Security must now be everyone's problem. Security must be baked into the software development lifecycle (SDLC), not brushed on at the end.
Asking the development and QA teams to focus on security can be a tall order, especially for those that have not been asked to do so in the past. We believe that fuzzing presents a unique vulnerability discovery methodology that is accessible to a wide audience due to the fact that it can be highly automated. While we are hopeful that seasoned security researchers will gain valuable insights from this book, we are equally hopeful that it will be accessible to developers and QA teams. Fuzzing can and should be an integral part of any SDLC, not just at the testing phase, but also during development. The earlier a defect can be identified, the less costly it will be to remediate.
