Web applications are the most commonly fuzzed application. That is because most in-house applications are web-based, most multiple components applications (server, script, database, and CGI) are bug-prone, it's a relatively young technology, and they typically require multiple languages to create one application.
One of my favorite tools for testing vulnerable web applications is WebProxy, from @stake (http://www.atstake.com/); it recently was acquired by Symantec (http://www.symantec.com). WebProxy is like the Swiss Army knife for web application testing: it contains all the tools to do everything quickly from your web browser, so there is no need to run multiple applications.
The features included in WebProxy are:
Interception of all browser requests (both HTTP and HTTPS)
On-the-fly editing of requests based on a matching regular expression
Resubmission and editing of previous requests
Regular expression substitution
Logging of requests and replies to files
Quashing of header parameters
Reloading of previously logged session
Cookie management utilities
Automated fuzzing of request parameters
Spidering with form and error detection
Automated forced browsing to find known vulnerabilities and configuration errors
Editing requests with XML bodies for web services and other complex applications
Using WebProxy is straightforward. Start up the Java app and configure your web browser to use HTTP proxy 127.0.0.1:5111 and HTTPS 127.0.0.1:5112.
To access the WebProxy application, open http://webproxy and everything should appear. Figure 22-4 shows what you will see and the usage of the different tabs.
The fuzzer engine provided in WebProxy is good, but somewhat limited in its testing capacity. The provided list of fuzz strings is minimal and it misses several important items. A good place to look for inspiration for fuzz strings is in the Spike source code (see The Spike API). The file spike.c contains a list of valuable fuzz strings that could be added to WebProxy. The current fuzz string provided in WebProxy is structured like the following code block:
... <string type="FormatStrings" rep="20" >%n</string> ... <string type="PathTraversal"> ../../../../../../../../../../../../etc/passwd</string> ... <string type="OddCharacters">%00</string> ... <string type="SQLInjection">'sqlattempt1</string> ... <string type="CrossSiteScripting"><script>alert(document.location); </script></string> ... <InterestingResult>(?i)odbc</InterestingResult> <InterestingResult>(?i)jdbc</InterestingResult> <InterestingResult>(?i)HTTP/[0-9].[0-9] 500</InterestingResult> ...
The strings shown are only a subset of the ones provided with WebProxy. However, even the full set is not sufficient and needs to be adapted, using the fuzz file specified in the config, depending on the kind of server you are attacking. When working with new languages, the error codes change from one platform to another, and these new error codes need to be added to ensure that most bugs are found. Also, different kinds of evasion techniques were discovered or added since WebProxy was written, including a Unicoded string and a VB script attack instead of Java.
WebProxy is not only a spider and a fuzzer, but can craft requests for doing search and replace on the wire. During most web assessments, I use WebProxy. While not being the most automated, it can do almost anything. Do not underestimate this small but utilitarian tool.