Workshop 01 · Web Security

Break the Web App, Then Learn Why It Broke

How web applications get broken: injection, broken authentication, and data left where anyone can read it. Learn what each flaw looks like and the defensive habit that stops it.

What You’ll Practice

Web challenges cover the flaws that show up most often in real applications — the kind listed in the OWASP Top 10.

Injection Flaws

Untrusted input handed straight to a database or command, letting an attacker change what the query does.

Broken Authentication

Login and session handling that can be bypassed by editing a cookie, a token, or a request parameter.

Exposed Data

Secrets left in page source, comments, backup files, or an API that returns more than it should.

Lesson 1 · WEB-01

Exposed Data: Secrets the Browser Hands Over

Everything a website sends to your browser can be read by you: the HTML, its comments, the JavaScript, and any file sitting in the public web folder. Developers sometimes leave notes, test passwords, API keys, or backup files there, assuming nobody will look.

This falls under security misconfiguration in the OWASP Top 10: the application is not broken in its logic, it is simply deployed with things it should never have shipped.

How it works

Attackers start with the cheapest checks: view the page source, open the browser developer tools, and request files that sites expose by habit, such as robots.txt, .git/, or backup.zip. A robots.txt file asks search engines to skip paths, which also advertises exactly where the interesting files are. 

<!-- TODO: remove before launch. Test account: admin / Winter2024! -->

# robots.txt
User-agent: *
Disallow: /old-backups/

How it is prevented

  • Keep secrets on the server or in a secrets manager, never in client-side code or comments.
  • Strip comments and debug code in the build step, and never deploy backups or the .git folder to the web root.
  • Run secret scanning on the code repository so leaked keys are caught before they ship.

Lesson 2 · WEB-02

Broken Access Control: Trusting the Client

Authentication answers who are you?; authorization answers what may you do? Access control breaks when the application lets the user decide the second question, for example by reading their role from a cookie or a hidden form field the user can edit.

Broken access control is number one in the OWASP Top 10 (2021).

How it works

If a site stores role=guest in a plain cookie and shows the admin panel when it reads role=admin, anyone can open the browser’s storage inspector and change the value. The server never checks. 

Cookie: session=7f3a...; role=guest

// vulnerable server logic
if (request.cookies.role === "admin") showAdminPanel();

How it is prevented

  • Keep the role on the server, tied to the session, and look it up on every request.
  • If a token must travel with the client, sign it (for example a signed session token) so tampering is detected.
  • Deny by default: check permission on the server for every action, not only by hiding buttons.

Lesson 3 · WEB-03

SQL Injection: When Input Becomes Code

Many applications build database queries from user input. If the input is pasted straight into the query text, the database cannot tell where the developer’s code ends and the user’s data begins, so a crafted input can change what the query does.

How it works

Below, the username is inserted between quotes. Input containing its own quote character closes the string early, and whatever follows is read as part of the SQL command, for example a condition that is always true, or a comment that removes the password check. 

-- vulnerable: input pasted into the query text
query = "SELECT * FROM users WHERE username = '" + username + "'"

-- safe: a parameterized query keeps input as data
query = "SELECT * FROM users WHERE username = ?"
db.execute(query, [username])

How it is prevented

  • Use parameterized queries (prepared statements) for every query that includes input.
  • Give the application’s database account only the permissions it needs (least privilege).
  • Validate input as a second layer, and never show raw database errors to users.

Lesson 4 · WEB-04

Insecure Direct Object References (IDOR)

An IDOR happens when an application fetches a record by an identifier the user supplies, such as an account number in a URL, without checking that this user is allowed to see that record. Being logged in is not the same as owning the data.

How it works

If your profile loads from an address ending in ?id=1001, an attacker simply tries 1000, 1002, and so on. When the server returns whatever it is asked for, every user’s record is one number away. 

GET /api/profile?id=1001   → your profile
GET /api/profile?id=1002   → someone else's profile (should be 403 Forbidden)

How it is prevented

  • On every request, check that the logged-in user owns or may access the requested record.
  • Prefer looking up the record from the session (for example /api/my-profile) instead of trusting an ID from the client.
  • Random identifiers make guessing harder, but they are not a substitute for the ownership check.

What You Take Away

The point of the web track is not the exploit itself but the defensive habit behind it.

  • Validate on the server

    Client-side checks are for convenience. Anything that protects data has to be enforced where the user cannot edit it.

  • Parameterize every query

    Prepared statements remove the ambiguity between code and data that injection depends on.

  • Check authorization per request

    A valid session says who you are, not what you may open. Verify ownership on every object you return.

  • Ship nothing you would not publish

    Comments, debug routes, and backup files in the web root are readable by anyone who looks.

Sources

  1. OWASP Foundation. (2021). OWASP Top 10: 2021. https://owasp.org/Top10/
  2. OWASP Foundation. (n.d.). SQL injection prevention cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
  3. BBC News. (2016, October 5). TalkTalk fined £400,000 for theft of customer details. https://www.bbc.co.uk/news/business-37565367
  4. Krebs, B. (2019, May 24). First American Financial Corp. leaked hundreds of millions of title insurance records. KrebsOnSecurity. https://krebsonsecurity.com/2019/05/first-american-financial-corp-leaked-hundreds-of-millions-of-title-insurance-records/
  5. Mintz. (2018, April 23). Failure to signal: Uber forced to accept expanded settlement after concealing security breach from FTC. https://www.mintz.com/insights-center/viewpoints/2826/2018-04-23-failure-signal-uber-forced-accept-expanded-settlement

Ready to put it into practice?

Try the Web Security challenges: capture the flags, score points, and unlock the explanation for each one.

Start the Web Security challenges Next workshop: Cryptography