EXERCISE 3 — The three moves, and the two login-bypass shapes
==============================================================

THE THREE MOVES: break out -> inject -> fix up.

PAYLOAD A:  admin'--      (full: admin'--␣ , dash dash space)
  Target query: WHERE username = '$u' AND password = '$p'
  After injection: WHERE username = 'admin'-- ' AND password = '...'

  1. BREAK OUT: the ' after "admin" CLOSES the username string literal,
     moving you from data position into code position. The username value is
     "admin".
  2. INJECT: ...here the "injection" is minimal — you're not adding logic, just
     selecting a specific user (admin) by leaving the username as a real value.
     (Move 2 can be empty/precise when you only need to target a row.)
  3. FIX UP: --␣ comments out the trailing  ' AND password = '...'  so the
     leftover password check and dangling quote are discarded and the query
     parses. Result: WHERE username = 'admin' -> returns the admin row.
  EFFECT: log in AS A SPECIFIC, NAMED user (admin) with no password.

PAYLOAD B:  ' OR '1'='1
  Target query: WHERE username = '$u' AND password = '$p'
  Submitted as username (password anything):
  After injection: WHERE username = '' OR '1'='1' AND password = '...'

  1. BREAK OUT: the leading ' closes the username string (username = '').
  2. INJECT: OR '1'='1' — always-true boolean logic.
  3. FIX UP: here NO comment is used; the payload is crafted so the TRAILING
     quote of the original query balances the quote the attacker opened on
     '1'='1 . The condition becomes (username='' OR '1'='1') AND password=...;
     because '1'='1' is always true and OR short-circuits the username test,
     the WHERE matches every row (operator precedence/AND aside, in the classic
     vulnerable form it returns all/any users).
  EFFECT: match ALL users -> logged in as whoever the app picks (often the
  first row).

HOW THE TWO SHAPES DIFFER:
  - admin'--  is PRECISE: you choose exactly which account to become (admin, or
    any username you know). It works by terminating the username and DELETING
    the password check via a comment.
  - ' OR '1'='1  is BLUNT: it makes the WHERE clause always true so it returns
    every user; you become whichever row the application selects (not your
    choice). It works by adding always-true logic rather than commenting.
  - Both are AUTHENTICATION BYPASS: access with no valid credential, from a
    query-construction flaw (Auth course link). Choose admin'-- when you know a
    target username and want control; ' OR '1'='1 when you just want in.

WHY PARAMETERIZED QUERIES ELIMINATE BOTH:
  - With  WHERE username = ? AND password = ? , the driver sends the query
    structure and the values on SEPARATE channels. The user input is BOUND AS A
    DATA VALUE and is never parsed as SQL.
  - So  admin'--  becomes a search for a username literally equal to the string
    "admin'-- " (which no real user has) -> no match. And  ' OR '1'='1  becomes
    a search for a username literally equal to "' OR '1'='1" -> no match. The
    quotes, the OR, the comment are all just characters in the data; they have
    zero syntactic power. Both bypasses fail. (Chapter 7 covers this in full.)

ONE-LINE TAKEAWAY:
  Read any payload as break-out / inject / fix-up; the two login bypasses
  differ in precision vs bluntness, but parameterization makes both inert by
  keeping the input as data.