Engineering Secure Software

Web Application Fuzzer

Overview

One of the most helpful tools that a security-minded software developer can have is a fuzz-testing tool, or a fuzzer. A fuzzer is a type of exploratory testing tool used for finding weaknesses in a program by scanning its attack surface.

The best fuzzers are highly customizable, so generalized fuzzers are often quite complex to configure and use, and can become out-of-date quickly. Fortunately, we're software engineers, so we'll build a fuzzer that can be customized to a specific product rapidly. The idea for this project is to create a suite of tools such that re-compilation is a normal part of the usage of your fuzzer.

For this project, you will be building a fuzzer for web applications. You may use any technology you like. For people who prefer Java, I strongly recommend using HTMLUnit, an automated web application testing library. Think of HTMLUnit like a GUI-less browser - it can simulate everything that a browser does from Java, and can test the results efficiently. In particular, HTMLUnit will:

• Handles the HTTP protocol, so you don't have to worry about networking details
• Parse HTML, so you can find inputs via relatively simple XPATH queries
• Simulate user actions, such as clicking links and submitting forms

Setup

1. Download the example-fuzzer.zip file. This is an Eclipse project and should be imported using File > Import > Existing Projects into Workspace
2. Use the XAMPP portable zip from the Web Application activity
3. Log into the BodgeIt web application in your browser. This is another intentionally vulnerable web application that we will be testing our fuzzer against.
4. Make sure you can get the given example code working.

Project Requirements

This project is for groups of 2-3 people, and not necessarily your case study group. Your fuzzer will need to do the following:

• Customizable to a given product within 20 minutes of configuration by your own selves in a development environment. Thus, you do not need a GUI, menu system, or anything fancy. Imagine that this is a testing tool you are building for your development and testing team.
• (15 pts) Page & Input discovery. Given a page, the fuzzer should attempt to discover every possible input into the system.
  • Parse URLs. The fuzzer should be able to take a URL and parse it down to manipulate its input and recognize which page a URL goes to. For example, http://localhost/index.jsp?something=a is the same page as http://localhost/index.jsp?anotherthing=b, and there are two input that can be fuzzed (something and anotherthing). Use Java's URL class to help with this.
  • Form parameters. All input fields to forms should be considered inputs.
  • Cookies. All cookies being set should be considered inputs.
  • Link discovery The fuzzer should keep a list of URLs that it can reach from an initial page. Do not follow any links off-site in your crawl.
  • Page Guessing. The fuzzer should use an external list of common URLs to discover potentially unlinked pages.
• (2pts) Time gaps. The fuzzer should allow a minimum period of time to wait between requests, where zero is a possibility
• (5pts) Lack of sanitization. Given inputs with data that should be sanitized, the fuzzer should report whether or not the data was actually sanitized.
• (5pts) Sensitive data list. As a tester, you might have some test data that you know is sensitive and should never be leaked. The system should contain a list of sensitive data, and should check each request if that data has been disclosed. This should be stored in an external text file.
• (3pts) Password authentication. Given a working password, the system should be able to handle authentication into the application.
• (5pts) External list of fuzz vectors. These are strings of common exploits to vulnerabilities. These lists can be found all over the internet. Start with this list at OWASP
• (2pts) Completness option (random|full). In Random mode, the fuzzer will randomly choose pages, input fields, and input texts. In Full mode, the fuzzer will try each text input on each field.
• (3pts) Password guesses (on|off). Given a list of common passwords, the fuzzer should check if the system allows easily-guessable passwords.
• (10pts) Meaningful output.
  • Potential vulnerabilities. The fuzzer should only report strange activity (such as system errors, http errors, or anything else that could indicate a vulnerability), or other useful information to a security tester. This output must remain readable to at least a security expert.
  • Attack surface. Provide a list of all the known inputs to the system that the fuzzer discovered.

Grading & Deadlines

• Submission. You have two choices on submissions: myCourses dropbox, or a third-party repository like GitHub. If you use a public repository for your project, let me know and I will pull your submission from there.
• Due 9-1, provide a report on the attack surface only report via GoogleDocs on DVWA, BodgeIt, and JPetStore. (You do not need to fuzz WebGoat, but feel free to use it as a reference.)
  • This should be a brief, 1 page report on the attack surface of DVWA that was discovered by your fuzz tester.
  • You may annotate the output of your page & input discovery feature. Readability counts, though.
  • Submit your code, as well.
• Due 10-2 a second report on potential vulnerabilities discovered in DVWA, BodgeIt, and JPetStore,
• The grading for this product is as indicated above (that part totals to 50 points). Additionally:
  • The initial attack surface report is worth 10 points
  • The final report is worth 10 points
  Thus, this project is worth 70 totals points.