With regard to cross-site scripting (XSS), a fuzzer can enter various browser scripts into a target Web application, varying the strings, functionality, encoding, size, and other aspects of the user input to see if a target Web application will reflect or store and return the input back to the researcher without any filtering. If the fuzzer's dangerous script does come back unimpeded, the target application is vulnerable to an XSS attack. An attacker can then enter a script into the application and get it to run on users' browsers.
In July 2007, Google publicly announced that it was working on an XSS fuzzer for its own internal use. The project, called Lemon, shows Google's awareness of the cross-site scripting threat and that fuzzers can help find such flaws. A few XSS vulnerabilities have been discovered in Google applications over the past year. Lemon is designed to find the flaws – and have Google fix them -- before attackers can exploit the vulnerabilities. Google has not released Lemon for public use, but its employees have talked publicly about the tool.
Other free, open source tools are starting to tackle the XSS fuzzing issue, including the WebScarab scanning tool from the Open Web Application Security Project (OWASP). The project has a nice write-up about how to use WebScarab as an XSS fuzzer.
Fuzzing is useful, but the testing process can't find all flaws. Fuzzing software tends to be pretty unintelligent; it just shoots a bunch of junk -- carefully selected junk, but junk nonetheless -- at a target hoping to find some weird reaction. The weird reaction, however, may be too subtle for the fuzzer to detect. Also, the input launched by the fuzzer may not cover all of the required technique combinations to trigger a flaw in the target software. Thus, fuzzing is not enough by itself to ensure a program is secure. Fuzzing should be part of a comprehensive software-testing regimen, which includes architecture review, code review and detailed testing.
This was first published in October 2007