Project 3: Web SecurityFall 2026

This project counts for 8% of your course grade. Late submissions will be penalized by 15% of the maximum attainable score. If you or your partner (if you’re working in a team) have a conflict due to travel, interviews, etc., please plan accordingly and turn in your project early.

This is optionally a group project; you may work in teams of two and submit one project per team. You may also work alone. Note that the exams will cover project material, so you and your partner should collaborate closely on each part.

The code and other answers you submit must be entirely your team’s own work, and you are bound by the Honor Code. You may discuss the conceptualization of the project and the meaning of the questions, but you may not look at any part of someone else’s solution or collaborate with anyone other than your partner. You may consult published references, provided that you appropriately cite them (e.g., with program comments).

Solutions must be submitted via the Autograder, following the submission checklist at the end of this spec.

Introduction

In this project, we provide an insecure website, and your job is to attack it by exploiting three common classes of vulnerabilities: SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). You are also asked to exploit various flawed defenses meant to prevent these attacks. Understanding how these attacks work will help you better defend your own web applications.

Objectives

• Learn to spot common vulnerabilities in websites and to avoid them in your own projects.
• Understand the risks these problems pose and the weaknesses of naive defenses.
• Gain experience with web architecture and with HTML, JavaScript, and SQL programming.

Ethics

This project asks you to develop attacks and test them, with our permission, against a target website that we are providing for this purpose. Attempting the same kinds of attacks against other websites without authorization is prohibited by law and may result in severe consequences. You must not attack any website without authorization!

Setup

Similarly to the Cryptography project, you will be using Docker to complete this project. However, if you haven’t already, follow our Docker guide to learn how to set up Docker on your computer.

1. To get the code for this project, create a repo using the GitHub template. Make sure to make this repo private.
2. Clone the repo onto your system (you’ll need to supply your GT credentials for this), then open it in VS Code.
3. If you successfully set up Docker in the previous project/labs, you should be greeted with a pop-up in the bottom right asking you to re-open the directory in the development container; do so now!
4. After some time taken to build the container, you should be greeted with the project files in a directory and a terminal connected to the container (as shown in the Docker guide).
5. Make sure the Docker container for Lab 3 is not running before you start the project. Both containers contend on port 3235 for displaying Firefox, so ensure that you’re seeing Firefox from the right container!

Resources

The browser Developer Tools introduced in Lab 3 will be instrumental for this project, particularly the JavaScript console and debugger, DOM inspector, network monitor, and cookie manager. You should familiarize yourself with the devtool documentation for your browser: Chrome, Safari, Edge, and Firefox.

Your solutions will involve manipulating SQL statements and writing web code using JavaScript, HTML, and Python. Tutorials and extensive documentation for these languages can be found online, and you can search the web for answers to basic how-to questions. We recommend these references:

• HTML Documentation
• JavaScript Document Methods
• SQLite SQL Syntax
• SQL Tutorial
• Introduction to HTML
• JavaScript 101
• HTTP Made Really Easy

To learn more about SQL Injection, CSRF, and XSS attacks, and for tips on exploiting them, see:

• OWASP Cheat Sheet Series
• XSS Filter Evasion Cheat Sheet

Primers

To help you get started on the background knowledge needed for this project, we’ve recorded a series of primer videos, one for each part:

• SQL and SQL Injection
• XSS and Web Inspector
• CSRF Overview

You can also download a PDF of the slide deck for all three videos here.

Guidelines

Browser

This project aims to be compatible with modern web standards and current versions of major browsers. However, it will be graded using Chrome 131.0.6778.108 on Linux. If your solutions depend on browser-specific behavior, you must ensure that they work within the grading environment. Furthermore, your solutions should be efficient and terminate in a reasonable amount of time.

Target Website

In the wake of a catastrophic cyberattack that occurred in 2026, GT hired a tech firm, Superb Computer People, to reconstruct its website to prevent future attacks. Unlike the Superb Computer People who developed the site, you took CS 3235, so the executives have hired you to perform a security evaluation before it goes live.

A beta version of the new site is available for you to test at https://gatech.rip. For “security” reasons, the site is only accessible after you register your group in the autograder and sign in through the official GT login portal.

Superb Computer People is reluctant to share implementation details, but they have disclosed that the site is written in Go, uses SQLite for its database, has a state-of-the-art authentication system, and is “completely secure.”

Subdomains

You have permission to explore, reverse-engineer, and test gatech.rip and all of its subdomains, including the following:

• Main page (gatech.rip)

  This is the university’s top-level domain. Here you’ll find “Quick Links” to useful services, as well as a variety of news stories.

• Search results (directory.gatech.rip)

  A directory of students and instructors. Everyone listed in the directory has an account on gatech.rip.

• Login handler (degreeaudit.gatech.rip)

  Degree Audit is a grading service similar to the autograder you use in your coursework. It provides different functionality depending on whether the logged-in user is a student or an instructor.

• Logout handler (sso.gatech.rip)

  This is the login service for gatech.rip.

Cookies

gatech.rip uses several cookies, described below, that you can experiment with. See the lab assignment for information about how to view, edit, and delete cookies within your browser.

auth

This cookie is used by gatech.rip to identify the currently signed-in user. When no user is signed in, the server sets it to a temporary guest value. Once signed in to a gatech.rip account, you can sign out by deleting the cookie.

AZURE_OAUTH

This cookie should be ignored, as it isn’t part of the project per se. Rather, we use it to ensure that only authenticated CS 3235 students can access the site. You don’t need to do anything with it, and your solutions shouldn’t depend on it being there.

Various tracking cookies

The site uses tracking cookies with a variety of names. These are not essential to the operation of the site, but you’re free to explore them.

HTML Elements

When crafting your solutions, you must include all HTML element values and ID’s exactly as they appear in the source code (without modification or concatenation) for your submissions to the autograder.

For example, if you want to submit an exploit that uses an HTML element with ID 'element_1e8f1a', you cannot submit something like 'element_' + '1e8f1a'.

Resetting the Database

In the course of your testing, it’s possible that you will cause gatech.rip to become unusable (e.g., by deleting the database). You can reset the underlying database at https://reset.gatech.rip.

Part 0. Metadata

Read Submission Details below and setup usernames.txt. The autograder requires this file to run your submissions!

Part 1. SQL Injection (SQLi)

Various aspects of the site utilize information stored on a database. Not that the Superb Computer People seem to care, but we have reason to believe that the directory search field is vulnerable to SQLi. Your first goal is to demonstrate SQL injection attacks that obtain information from the gatech.rip database, which are itemized below.

1.1 Error result 3 pts

Create a search query that causes a 500 Internal Server Error.

Submission: sql_1.txt

1.2 Extract schema 4 pts

Create a search query that extracts the schema of the gatech.rip database and causes a 500 Internal Server Error. It is okay if additional extraneous information is retrieved during your query.

Submission: sql_2.txt

1.3 Extract table 4 pts

Create a search query that extracts all rows from the table containing student information and causes a 500 Internal Server Error. It is okay if additional extraneous information is retrieved during your query.

Submission: sql_3.txt

1.4 Cookie theft 7 pts

Initially, you are not logged into any account on gatech.rip. However, the site assigns you a temporary auth cookie for guest account. Change the auth cookie to any value that will cause you to be signed in as a non-guest account, and submit the new value.

Submission: sql_4.txt

1.5 Account addition 7 pts

Craft a search query that will add an account with the username victim to the gatech.rip database. All other fields can be set arbitrarily.

You can test this by executing the query, and “signing in” with the same method you used in 1.4.

Submission: sql_5.txt

1.6 Escaping and Hashing 15 pts

An anonymous tip has been received by the executives claiming that gatech.rip login service (https://sso.gatech.rip) may have a SQLi vulnerability.

Apparently, in the login form, the server escapes the provided username and applies the SHA-256 hash function to the string scp- concatenated with the encoded password.

The tipper has conducted some basic reverse-engineering to represent what they suspect the server does when the login form is submitted (in Python):

def login():
    username = request.form["username"]
    escaped_username = sql_escape_string(username)

    password_bytes = ("scp-" + request.form["password"]).encode("latin-1")
    password_digest = sha256(password_bytes).digest().decode("latin-1")

    query = "SELECT * FROM accounts WHERE username='" + escaped_username + "' AND password='" + password_digest + "'"
    selected_users = sqlite.execute(query).fetchall()

    if len(selected_users) > 0:
        return "Login successful!"
    else:
        return "Incorrect username or password."

Your task is to find a username:password combination that will successfully log you in as the user with that username. The username you submit must be from an existing account (not one you added).

This is more difficult than the previous parts. You will need to write a script to produce a working exploit. You can use any language you like, but we recommend Python 3.

Submissions: sql_6.txt and sql_6-src.zip (See What to Submit below).

1.7 Database Enumeration EXTRA CREDIT!

This target uses a different database.

Your job is to use SQL injection to exploit https://directory.gatech.rip/extracredit to retrieve:

• The name of the database file
• The version of the SQLite engine
• All of the names of the tables in the database
• A secret string hidden in the database

Submission: sql_7.txt

For this part, the text file you submit should start with a list of all the queries you made to learn the answers. Follow this with the values specified above, using this format:

*QUERY*
*QUERY*
*QUERY*
...

File: *DB filename* (not the full path, just the filename)
Version: *DB version string*
Tables: *comma separated names*
Secret: *secret string*

This target is exceptionally difficult, and therefore completing it successfully will count as extra credit. However, the course staff are not able to provide help on the parts labeled as extra credit.

What to submit

For 1.1-1.3 and 1.5, submit a text file that contains a single line consisting of a search query to be executed on the directory search field. For 1.4, submit a text file that contains a single line consisting of the value of an auth cookie that will be set on directory. For 1.6, along with the actual username and password in a text file, also submit the source code for the program you wrote by placing it in a folder, then creating a zip file of the folder named sql_6-src.zip. For 1.7, submit a text file as specified.

Part 2. Cross-site Scripting (XSS)

Your next task is to demonstrate XSS attacks against directory. For each of the parts below, your goal is to construct an input that, when interpreted by gatech.rip, correctly executes the specified payload. We recommend that you begin by testing with a simple payload (e.g., alert(0);), then move on to the full payload.

Target Input Fields

In the directory, each student has their own profile! These profiles are full of interesting information such as role, email, phone number, etc. A user is allowed to customize their About Me section using the relevant form that appears when viewing their own profile. A user can also add a new Also Known As name with a similar form on their own profile.

The executives are suspicious that these fields are potential XSS vulnerabilities, and have asked you to ensure they are secure. They even reached out to Superb Computer People, but they seem to be on vacation.

Payload

For 2.1 and 2.2, you will be constructing a payload that steals the full name of anyone who views a particular user’s profile.

For purposes of grading, your attack should report this data by sending a GET request to URLs of the form http://localhost:31337/?stolen_user=<full_name>, where <full_name> represents the full name of a user viewing the site. It is alright if spaces inside the full name text are URL-encoded (e.g., %20), but no extra whitespace or text should be included. In your attack, the request should include the string localhost or 127.0.0.1 verbatim, without concatenation or modification.

You can test receiving this data by running this command within the Docker container:

$ python3 -m http.server 31337

and observing the HTTP GET request that your payload generates in the server log.

For full credit, make sure your payload functions exactly as specified above. We cannot accept solutions that load an incorrect URL or use an incorrect request method. You may not use any vulnerabilities from Part 1 to complete this part.

2.1 About Me Viewer Tracker 10 pts

Login as a user using the method you learned in 1.4 or 1.6, and ensure your payload works when submitted as a new About Me section.

A successful attack will send a request whenever a user views this profile.

Submission: xss_1.txt

2.2 Also Known As Viewer Tracker 10 pts

The Also Known As section of each profile is similar to the About Me section, but Superb Computer People seems to have already attempted to defend against XSS! This field filters out some tags and punctuation using the following Go function:

func filterInput(input string) string {
    pattern := `(?i)(script|<body|<img|<style|<meta|<embed|<object|[;'\[\]"])`
    re := regexp.MustCompile(pattern)
    return re.ReplaceAllString(input, "")
}

Login as a user using the method you learned in 1.4 or 1.6 and modify your 2.1 payload to work when submitted as a new Also Known As section.

A successful attack will send a request whenever a user views this profile.

Submission: xss_2.txt

2.3 samy is my hero 15 pts

Create a worm that can be placed as an About Me for any single user and includes the phrase:

but most of all, samy is my hero.

Additionally, the worm must change the About Me for anyone who views the user’s profile to include the same phrase, and continue to spread to anyone who views any profile containing the it. This attack should be able to spread infinitely. Note this payload will be different than the one used in 2.1 and 2.2.

You can test this by setting an initial user About Me to the worm, then sign in to a different account, and then check if viewing the initial user’s profile changes the different user’s About Me to contain the worm. It may be helpful to log into two different accounts on separate browsers to avoid the need to continually log in and out.

Submission: xss_3.txt

What to submit

For parts 2.1 and 2.3, submit a text file whose contents can be directly submitted as a new About Me for any signed in user and achieve the desired result. Do the same for part 2.2, except with something that can be submitted as a new Also Known As.

Part 3. Cross-site Request Forgery (CSRF)

Your final goal is to demonstrate CSRF vulnerabilities against various forms within gatech.rip. For each of the parts below, you will be creating an HTML file that, when opened by a victim, performs the specified attack. You may not use any vulnerabilities from any prior parts to complete this part.

To test your solutions locally, you will need to open HTML files from within your browser. Please reference the lab assignment for instructions on how to do so.

3.1 Update Score Mischief 10 pts

Imagine you are a student user of Degree Audit (https://degreeaudit.gatech.rip). You have submitted your code, but don’t want to go to the trouble of fixing bugs for it to pass the autograder. Instead, you choose to search for a bug on Degree Audit that allows you to raise your score.

Log in as an instructor (“TA”) using a similar method you used in 1.4 or 1.6, and view a student submission. You will see a form that allows an instructor to change a student’s grade with a POST request. We have reason to believe the site may also allow GET requests to this endpoint.

Your Task

Create an HTML file which, if opened by an instructor, will change a specific submission’s score. The file should change the score of the first Degree Audit submission in the database (i.e. with id=1), to 100/100.

Your solution should not require any user action beyond an instructor loading the page once. The browser may redirect after opening the HTML file.

To test your solution, log in as an instructor, and open your HTML file in a new tab on your browser.

Submission: csrf_1.html

3.2 Image Submission Forgery 15 pts

The gatech.rip homepage has several subpages, including one with resources for current students (https://gatech.rip/life/campus). This page features a gallery of images uploaded by students on the directory.

Each image is labeled with the username of the student who uploaded it. The executives want to ensure that all images in the gallery are legitimately uploaded, so they forced Superb Computer People to implement enhanced security measures.

When you go to the current students page, you will notice a form that uploads images to the gallery with a POST request. We have reason to believe the site may also allow GET requests to this endpoint.

To please the executives, the Superb Computer People have configured gatech.rip to set a cookie named csrf_token to a random 32-byte value and also include this value as a hidden field in the upload form. When the form is submitted, the server verifies that the client’s cookie matches the value in the form.

Your Task

Create an HTML file that will submit a photo on behalf of a logged-in user upon the user opening the file in their browser. The photo must have https://gatech.fail/img/logo.png as its URL. The caption can be set arbitrarily. After opening the file, the image must be posted on the website with the logged-in user’s name attached.

Your solution should not require any user action beyond a logged-in user loading the page once. The browser may redirect after opening the HTML file. You are allowed to exploit XSS vulnerabilities within the page.

To test your solution, log in as any user, and open your HTML file in a new tab on your browser.

Submission: csrf_2.html

What to submit

For both parts, submit an HTML file that accomplishes the specified attack against the specified target.

Tips and advice

In the past, students have lost credit on this part for various preventable reasons. Here are some tips on how to avoid common pitfalls:

• Double check to make sure you use the exact target endpoints specified.

• Do not rely on JavaScript methods that force the script to sleep for a hard-coded time interval, as this approach may not work consistently across all situations.

• When obtaining cookie data, avoid hardcoding any values beyond those given above. Search online to find general best practices for these tasks.

• Apply the security mindset and test your exploit thoroughly, multiple times just to be safe! Make sure to clear any cookies and disable any extensions that may interfere.

Part 4. Feedback

This is a new project for 3235 (the first time we have ever run it).

To help us improve the project for future semesters we would really appreciate feedback!.

Here are some topics you might discuss:

• Any aspects of the project that you found confusing or under-defined
• Ways you think the project could be improved
• Any security vulnerabilities within gatech.rip that were not covered in the project parts
• Any parts of the project you particularly enjoyed

Please provide your feedback in a text file, in the form of an itemized list.

Submission: part4.txt

Submission Details

1. Create a repo using the GitHub template. Make sure that the repo you create is private.

2. Visit the project on the autograder, and optionally create a team. Ensure that only one team member makes submissions to the Autograder to avoid confusion.

3. Create a file in your repo named usernames.txt that contains your GT username(s), one per line (e.g. gburdell3):

<username_1>
<username_2>

Web Project Autograder

Ensure the following items are completed and submitted by the deadline:

Part 1: SQL Injection

Part 2: XSS

Part 3: CSRF

Part 4: Feedback