Project 2: WebWinter 2025

This project counts for 9% of your course grade. Late submissions will be allowed with the use of late days.

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 final exam 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 are not allowed to give or accept solutions or hints, whether from someone else or from an AI. You may consult published reference materials, provided that you appropriately cite them (e.g., with program comments). Visit the course site for the full collaboration policy.

Solutions must be submitted to the autograder following the submission checklist.

Useful Links

• Docker setup guide
• Starter code
• Autograder
• umich.eu

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.

Target Website

In the wake of a catastrophic cyberattack that occurred in 2023, UofM hired a tech firm, MUNGLE!, to reconstruct its website to prevent future attacks. Unlike the Munglers who developed the site, you took EECS 388, 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://umich.eu. For “security” reasons, the site is only accessible after you register your group in the autograder and sign in through the official UofM login portal.

MUNGLE! 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 umich.eu and all of its subdomains, including the following:

umich.eu

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.

mcommunity.umich.eu (MCommunity)

MCommunity provides a directory of students and instructors. Everyone listed in the directory has an account on umich.eu.

gradebook.umich.eu (Gradebook)

Gradebook 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.

weblogin.umich.eu

This is the login service for umich.eu.

Cookies

umich.eu 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 umich.eu 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 umich.eu account, you can sign out by deleting the cookie.

GOOGLE_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 EECS 388 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'.

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.

Tools and Resources

The browser Developer Tools introduced in Lab 2 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:

Resetting the Database

In the course of your testing, it’s possible that you will cause umich.eu to become unusable (e.g., by deleting the database). You can reset the underlying database at https://reset.umich.eu or by clicking the button below. Be aware that you will lose any data you have added to the site.

Reset Database

Part 1. SQL Injection (SQLi)

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

1.1 Error Result

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

Submission: sql_1.txt

1.2 Extract Schema

Create a search query that extracts the schema of the umich.eu 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

Create a search query that extracts all rows from a 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

Initially, you are not logged into any account on umich.eu. However, the site assigns you a temporary auth cookie for uniqname guest. Change the auth cookie to a 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

Craft a search query that will add an account with the uniqname victim to the umich.eu 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

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

Apparently, in the login form, the server escapes the provided uniqname and applies the SHA-256 hash function to the string mungle- 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 = ("mungle-" + 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 uniqname:password combination that will successfully log you in as the user with that uniqname. The uniqname 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.

Submission: sql_6.txt and sql_6-src.zip (see What to submit below)

1.7 The SQL Extra credit

This target uses a different database.

Your job is to use SQL injection to exploit https://mcommunity.umich.eu/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 MCommunity 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 MCommunity. 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 MCommunity. For each of the parts below, your goal is to construct an input that, when interpreted by umich.eu, 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 MCommunity, 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 MUNGLE!, 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 encoded or extraneous messages appear within your response. 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 Tracking

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 Tracking

The Also Known As section of each profile is similar to the About Me section, but MUNGLE! 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

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

but most of all, samy is my hero.

to that user’s profile. 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 umich.eu. 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 Part 1 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

Imagine you are a student user of Gradebook (https://gradebook.umich.eu). 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 Gradebook 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 Gradebook 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

The umich.eu homepage has several subpages, including one with resources for current students (https://umich.eu/current-students). This page features a gallery of images uploaded by students on MCommunity.

Each image is labeled with the uniqname of the student who uploaded it. The executives want to ensure that all images in the gallery are legitimately uploaded, so they forced MUNGLE! 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 Munglers have configured umich.eu 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://eecs388.org/img/flag.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:

• 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.

Part 4. Feedback Extra credit

This is a brand-new project for 388, and the first time we have ever run it. While we are very excited to see how you all perform, we do understand there may be some oversights on our part.

To help us improve the project for future semesters, we are offering an opportunity for students to earn a small amount of extra credit by providing us certain feedback.

Here are some topics you may 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 umich.eu 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. Establish a team on the autograder. Only teams created on the autograder will be able to view the project site and join the online office hours queue.

3. Create a file in your repo named uniqnames.txt that contains your uniqname(s), one per line:

<uniqname_1>
<uniqname_2>

Project 2 Autograder

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

Part 0: Metadata

Part 1: SQL Injection

Part 2: XSS

Part 3: CSRF

Part 4: Feedback

Once you’re done with the project, you can delete the Project 2 Docker container to reclaim resources on your computer. Don’t uninstall Docker (you’ll need it for future projects), just the container.