|
In short, yes, it is. For the uninitiated, fuzzing is the process of finding flaws in software by sending it varying input repeatedly, trying to cause the target program to hiccup or crash. For years, researchers have used fuzzers effectively to find buffer-overflow flaws. In such analyses, the researcher can use tools like the free General Purpose Fuzzer or the commercial Mu-4000 fuzzing appliance. To look for an elusive flaw, a fuzzer may send billions of user input variations over the course of several weeks, automating the analysis process. There are a lot of free fuzzers that offer such services.
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.
More information:
Author Michael Sutton discusses fuzzing in the enterprise.
Will the Sulley framework take fuzzing to the next level? Senior News Writer Bill Brenner talks with the tool's creator.
|
