More fuzzing logic
So why not do illegal things with the protocol, too? Why not just send a zillion FF bytes? First, proxy servers will usually block out transmissions that are illegal at the protocol level, so application handlers dont usually have to deal with them. Second, there are an infinite number of possible attacks of this type, and they dont usually result in anything of interest, so its a black hole from the testing standpoint. Even while staying legal, there are test cases with a theoretically infinite series of possibilities. Consider an HTML <A> tag with multiple hrefs in it: <A href="sdfsdf" href="sdfsdf" href="sdfsdf"...> For purposes of practicality, you can cap the number of these at some very high value.beSTORM is designed to be used in a development environment in concert with a debugger, in order to elicit errors in the application being tested, such as subtle overflows. This is a difficult task to do in a user environment, another problem with much testing. A large beta test, for example, is a good thing to do, but its not likely to find abusive error cases of the type beSTORM is designed to catch. Thoroughly exercising a protocol can result in a very large number of test cases and a long test period, but the automation can minimize the impact. Beyond Security claims that beSTORM has optimizations that allow it to focus first on cases that are more likely to produce results. And even better, by dividing up the test cases into sections, the tests can be made parallel, and you can often get linear scalability just by adding systems to the test. This is one way to mitigate the testers dilemma I described above. Fuzzing is not just about network applications. There are many classes of applications for which it is useful; consider database applications, where the database programming protocol could be fuzzed. My personal favorite is window messaging, the protocol on Windows and other GUIs wherein windows send messages to one another. Especially in Microsoft Windows, this has been the subject of much vulnerability research in the last few years, and attacks on them (called "shatter" attacks) have potential for privilege escalation. A next-generation fuzzer could be an important tool, and could result in a period of rapid vulnerability exposure. In the longer term, as testing like this becomes routine, such errors could become rare, which is a delightful scenario. Today they are all too common. Fuzzing isnt the end game in testing, since it addresses only certain classes of errors, but the more testing we do, the better security generally will be. Editors Note: This story was updated to correct the spelling of the beSTORM product name. We also changed the reference to the original fuzzing tool to Fuzz. Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.
More from Larry Seltzer
For advice on how to secure your network and applications, as well as the latest security news, visit Ziff Davis Internets Security IT Hub.