Exercises — Security — OWASP Top 10, input validation, authentication vs authorization

Answer: A01 — Broken Access Control (specifically IDOR, Insecure Direct Object Reference). WHAT happened: the app checked who the user is (they were logged in) but never checked whether this user may act on object 6. WHY it is A01 and not A07: A07 (Auth Failures) is about the login/identity step breaking; here login worked perfectly — it is the permission step that is missing. That is authorization, hence A01.

Answer: A03 — Injection, sub-type SQL injection. WHY: untrusted input closes the quote and adds OR '1'='1', so data became code — the defining property of every injection flaw.

Answer: A02 — Cryptographic Failures. WHY: the secret is protected with a fast, unsalted hash — vulnerable to rainbow tables and brute force. The failure is in how the secret is stored, not in identity or permission checks.

cur.execute("SELECT * FROM users WHERE email = ?", (email,))

WHY this works: the ? is a bound parameter. The driver compiles the query template first into a fixed parse tree, then attaches email as a pure leaf value. Recall the parent note's model: with concatenation $\text{query}=T++u$, the input $u$ can add nodes to the parse tree $P(\text{query})$. With parameterization $P_{\text{parsed}}=P(T)$ — the tree depends on $T$ alone, so no character in email can change it.

Encode for the HTML-body context: <script>steal()</script> WHY: the browser now displays the characters instead of parsing them as a <script> element. Same bytes of data, neutralized by encoding for the destination context. (If the same value went into an HTML attribute or a URL, you'd encode differently — context matters.)

db.save(user, bcrypt.hash(password, work_factor=12))

(bcrypt/argon2 generate and embed a per-user salt automatically.) The two properties:

1. Salt — identical passwords hash differently, so precomputed rainbow tables are useless.
2. Work factor — the hash is deliberately slow and tunable, making mass guessing economically infeasible.

Answer: identifiers (table/column names) and dynamic ORDER BY / LIMIT clauses. Parameter binding only works for values (leaves of the parse tree). You cannot bind a column name — so code like ... ORDER BY " + sortField is still injectable. WHY: binding replaces a leaf; a table or column name is structure, not a value, so the driver has no slot to bind it. Fix: allowlist those identifiers against a fixed set (e.g. sortField in {"date","amount"}).

WHY the order: authorization is the question "may THIS subject do THIS action?" — it cannot be answered until the subject is known. Identity (AuthN) supplies the subject; permission (AuthZ) evaluates a rule about that subject. No subject ⇒ no rule to evaluate. Anonymous access is not the absence of authorization — it is authorization where the subject is fixed to "anonymous", and the rule happens to allow it. So the pipeline is always AuthN → AuthZ, even for public pages.

A02 — Cryptographic Failures (a secret, the session token, travels in cleartext and can be sniffed) and A07 — Identification & Auth Failures (a stolen session token lets an attacker impersonate the user, defeating identity). WHY two: the transport flaw is cryptographic; the consequence is a broken identity guarantee. One root cause, two distinct impacts — a classic Threat Modeling insight: trace a weakness to all the properties it violates.

Ordered pipeline:

1. Transport = HTTPS — defends A02 (token/secret not sniffable). See HTTP and Web Fundamentals.
2. Authenticate the session/token — defends A07: establish who (the subject). See Sessions and Tokens (JWT, OAuth).
3. Validate {id} against an allowlist shape (e.g. integer) — defends A03: no injection via the path parameter.
4. Authorize per-object: load the order, check order.owner_id == current_user.id and that the user's role permits refunds — defends A01, applying Principle of Least Privilege.
5. Default-deny if any check is missing/false — return 403.

WHY this order: you cannot authorize (step 4) before you know the subject (step 2), and you should not trust {id} (step 3) before using it to look up the object. Each layer removes one attack class; skipping any one re-opens it.

allowed = {"name", "price", "created_at"}
if col not in allowed:
    raise ValueError("bad sort column")
cur.execute(
    "SELECT * FROM items WHERE name LIKE ? ORDER BY " + col,
    ("%" + term + "%",),
)

WHY: term is a value → parameterize it (the %...% wrapping is applied to the bound value, not to the SQL text, so it can't break out). col is a structural identifier → it cannot be bound, so allowlist it against a fixed set before interpolating. Two different tools because they defend two different parse-tree positions.

Each $+1$ in $w$ doubles the cost per hash, so it halves the guess rate. Going from $10$ to $14$ is $4$ increments: $\text{rate}=N\cdot \frac{1}{2^{14-10}}=\frac{N}{2^4}=\frac{N}{16}.$ Answer: $\frac{N}{16}$ — the attacker's throughput drops to one-sixteenth. WHY this matters: defenders pay the cost once per login; attackers pay it once per guess. The work factor is a lever that hurts brute force far more than legitimate use — the core economic idea of Cryptography Basics.

A 32-bit salt has $2^{32}$ possible values, and each demands its own precomputed table entry: $2^{32}=4294967296\approx 4.29\times 10^9.$ Answer: the table must grow by a factor of $2^{32}\approx 4.29$ billion — per password. WHY: the salt makes identical passwords hash differently, so a single shared table no longer works; the attacker is forced back to per-user brute force. That is exactly why salting kills rainbow tables.

A 6-digit OTP has $10^6=1,000,000$ possibilities. Guessing uniformly at random, the expected number of attempts to hit it is about half the space: $\frac{10^6+1}{2}=500,000.5\approx 5\times 10^5.$ With a 5-try lockout, the success probability per session is $\frac{5}{10^6}=5\times 10^{-6}$, i.e. 1 in 200,000. WHY it changes the game: unlimited attempts guarantee eventual success; the lockout turns a certainty into a tiny probability. This is why A07 explicitly flags missing rate-limiting as an authentication failure.

L1 — naming the door that broke (identity gate A07 vs permission gate A01 vs data-as-code A03). L2 — replacing "clean the note" with "separate the note from the instructions" (parameterize, encode, hash+salt). L3 — noticing the gaps a defense leaves (identifiers, second-order, transport). L4 — chaining AuthN → validate → AuthZ → default-deny into one pipeline. L5 — counting the attacker's cost and realizing math and process must both be present. One thread ties them all: never trust input you didn't generate, and always separate WHO from WHAT.