FuzzDB is an open source database of attack patterns, predictable resource names, regex patterns for identifying interesting server responses, and documentation resources. It’s most often used testing the security of web applications but can be useful for many other things. FuzzDB started off as years of my own personal documentation and research notes and gradually evolved into its current form.

The problem that led to the creation of FuzzDB

What kinds of things are in FuzzDB

The different ways in which FuzzDB could be used

The future of FuzzDB This is the first of a series of blog posts about FuzzDB. It discusses: FuzzDB, is hosted at Google Code: https://code.google.com/p/fuzzdb/

Thinking About Test Cases



A lot of attention has been paid to identifying attackable surface areas, but less to the development of attack pattern libraries. When we dynamically test web applications for security vulnerabilities, how good are the test cases we’re using?

Commercial web scanning tool vendors put significant research effort into this problem, but the product of this research is considered intellectual property and locked up inside the application. As users, in order to learn what kinds of test cases are being generated we would need to painstakingly record and analyze its traffic. At the time I initially released FuzzDB, most open source web fault injection tools had sets of test cases which were woefully incomplete and inadequate. There are too many permutations of symbols and encodings used in web protocols for anyone to reliably and repeatably recall all of them. As for the commercial tools, how complete are their sets of test cases, anyway? It’s not always easy to tell. What were they actually testing for? These tools aren’t just test case lists, they’re lists wrapped in complex sets of rules that determine which test cases to use when and where. After considering these details, I had some doubts about the effectiveness of the typical application testing process.

My thoughts turned to increasing the speed and accuracy with which I could find certain classes of vulnerabilities during assessments. I began collecting, categorizing, and using lists of attack strings and of common file and directory names. Eventually I organized them into what is now FuzzDB and made it freely available under an Open Source license, the Creative Commons Attribution license.

As with any tool, an individual with malicious intent could potentially use FuzzDB in bad ways. However, I believe that it’s better to provide this information for the security of all. More importantly, if developers and testers have access to a good set of test cases, software will be released that has already passed this list of test cases.

That’s my ultimate goal for FuzzDB: for it to become obsolete as an attack tool because the applications become more secure. When applications and frameworks are inoculated against its patterns through testing and secure coding techniques, bad actors will no longer find the patterns in FuzzDB to be useful.

What’s in FuzzDB?

Predictable Resource Locations – Because there are a small number of popular server OS and infrastructure application packaging systems, resources such as logfiles and administrative directories are typically located in a small number of predictable locations. FuzzDB contains a comprehensive database of these, categorized by OS platform, web server, and application. The intent is for a tester to use these lists to be able to make educated rather than brute-force guesses, significantly increasing the likelihood of successfully forcible browsing interesting and vulnerable resources. Also, they’re appropriate to be used in creating automated scanners as well as IDS/IPS signatures.

Attack Patterns – The attack pattern test-case sets are categorized by platform, language, and attack type. These are malicious and malformed inputs known to cause information leakage and exploitation. FuzzDB contains comprehensive lists of attack payloads known to cause issues like OS command injection, directory listings, directory traversals, source exposure, file upload bypass, authentication bypass, http header crlf injections, and more.

When I say “malicious inputs,” I mean it. Downloading the project may cause antivirus alerts or trigger pattern-based malicious code sensors. While FuzzDB is itself nothing but a collection of text files that are harmless on their own, some of the patterns included in the files have been used extensively in worms, malware, and other exploits.

Response Analysis – Since system responses also contain predictable strings, FuzzDB contains a set of regex pattern dictionaries such as interesting error messages to aid detection software security defects, lists of common Session ID cookie names, regex for numerous Personally Identifiable Information, and more.

Documentation – Helpful documentation and cheatsheets sourced from around the web that are relevant to the payload categories are provided.

Other useful stuff – Webshells, common password and username lists, and some handy wordlists.

What can FuzzDB be used for?