CS177: Project 3 - Web Security (20% of project score)

Project Goals

The goals of this project are:

  • to understand and exploit a SQL injection vulnerability [12% of project score]
  • to understand and exploit a parameter injection vulnerability [8% of project score]

Administrative Information

The project is an individual project. It is due on Thursday, May 7, 2020, 23:59:59 PST (no deadline extensions; late flags will not be accepted).

Injection vulnerabilities in web applications

The goal of this project is to find (and exploit) vulnerabilities in two web applications. The first app contains an SQL injection flaw, the second one suffers from a parameter injection bug.

Injection vulnerabilities are a major concern when developing web applications. In fact, the Open Web Application Security Project (OWASP) has "Injection Vulnerabilities" as the number one entry in their list of the Top 10 web application security risks. Injection flaws, such as SQL, NoSQL, operating system injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

For this project, we remotely run two vulnerable web applications. Like for previous challenges, you will first go to our CTFd site and launch your service instances. The site will give you the address and destination port where your server is running and listening for your connections. For this challenge, you don't need to implement any client. Instead, you can directly connect with a web browser of your choice. Once you have exploited the vulnerability in one of the applications and obtained your flag, just submit it via the CTFd site and collect your points.


In a first step, it is always helpful to play around with the application. Try to understand what functionality the application implements, and how it does it. Try a few different inputs and get a feeling for what is happening. Look for errors when you pass in unexpected inputs.

The HTML source code of the application is often a helpful source of information. Always check it and understand what is going on under the hood of what the browser shows you.

For the first application, you are given the username and password for one user. That username is dummy and the password is dummy as well. Clearly, this is not a very secure password choice ;-).

When you explore the first application, try to force the web app to produce an error message (remember that you are testing for an SQL injection vulnerability). Then, use the information in the error message to iteratively extract more information from the database.

The database that is used by the first application is SQLite (from their website: "SQLite implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine"). Thus, you need to ensure that your injected queries follow the SQLite syntax. This article provides a good overview of how to inject SQLite database based applications.

The first application stores the flag in an entry in the database. As a small, additional challenge, the app will encrypt the flag value when it recognizes it as part of output that is sent to the user. You will have to find a way to work around this simple protection mechanism.

The second application calls Unix/Linux utilities to perform its task. Try to understand how it uses the inputs that you provide as part of these commands, and try to understand how you can manipulate the commands by injecting unexpected inputs.

For the second application, the flag is stored in a file on the file system. You might have to look around a bit and try to locate the right directory where the flag file is located. Then, try to access the content of this flag file.