Project Goals
The goals of this project are:
- to understand and exploit a SQL injection vulnerability [10% of project score]
- to understand and exploit a file inclusion vulnerability [4% of project score]
- to understand and bypass an access control vulnerability [6% of project score]
Administrative Information
The project is an individual project. It is due
on Friday, May 12, 2023, 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 three web applications. One app (called
"SQL-Injection") contains an SQL injection flaw. One app ("Backend
Server Misconfigurations") suffers from a file inclusion
vulnerability. One web app ("Authentication Bypass") is using a
vulnerable access control mechanism.
Injection vulnerabilities and broken access control flaws are
major concerns when developing web applications. In fact, the
Open Web Application Security Project (OWASP) has "Broken Access
Control" and "Injection" vulnerabilities as the number one and
number three entries in their list of the Top 10
web application security risks. Injection flaws, such as
SQL injection or command 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. Broken access control includes a variety
of problems that can lead to unauthorized information disclosure
or modification of sensitive data.
For this project, we remotely run three vulnerable web
applications (or, rather, three versions of the same
application). 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.
Hints
In general, it is always helpful to first play around a bit with
the applications. Try to understand what the application does,
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. Sometimes, a developer might leave an important hint there
:-).
The following paragraphs provide some more detailed hints for the three individual applications.
-
For the "SQL-Injection" application, you are given the username and
password for one user. That username is cs177 and
the password is cs177 as well. Clearly, this is not
a very secure password choice ;-).
When you explore the 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 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 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 "Backend Server Misconfigurations" application includes a
link that opens a local document. Try to understand how the app
creates the filename, and see if you can manipulate this value
somehow.
The flag is stored in a file on the file system. You will need
to do a bit of sleuthing to find the location of the flag file
on the file system.
If the app tries to prevent your direct attempt to trick it,
think about ways in which you can encode your inputs.
-
For the "Authentication Bypass" app, you are again given the username and password
for one user. Again, that username is cs177 and
the password is cs177. When you sign it, the
app creates a session, using a JSON Web Token (JWT) access
control token. JWT is a mechanism that can be used safely, but
there are also things that can go wrong. In fact, OWASP does
explicitly call out "metadata manipulation, such as replaying or
tampering with a JSON Web Token (JWT)" as a common problem.
Your goal is to manipulate the JWT token and trick the web
application into thinking that you are an administrator. To this
end, you need to add "isAdmin":"true" to the metadata
of the token. If the web app recognizes you as the admin, it
will send you the flag.
Of course, the situation is not as easy as simply putting the
additional metadata into the JWT token. After all, these tokens
are cryptographically protected! Or are they :-)? This article
might contain helpful pointers to see how to work around such
protections.
The browser's developer tools are your friend. They allow you to
easily view (and change) the values of cookies locally, before
they are sent to the web app.