A03 — Injection Insecure

1000-ft view: these examples show what NOT to do — string concatenation into SQL, trusting stored fields later (“second-order” injection), and rendering user content without encoding. Try classic payloads like ' OR '1'='1' --, %25%27%20UNION%20SELECT…, or <script>alert(1)</script> to see the risks.

Compare with the Secure version.

Attack 1 — SQL Login Bypass

string concat + plaintext check

Vulnerable idea: build the query with user input: WHERE email='$e' AND password_hash='$p'. A payload like email = ' OR '1'='1'-- can bypass authentication.

  1. Try email: ' OR '1'='1'-- (note the space after --).
  2. Use any password. If the query returns a row, the code “logs you in.”

Attack 2 — UNION Search

LIKE '%$q%' + UNION

Vulnerable idea: interpolate $q into a LIKE and allow shape-compatible UNION SELECT to exfiltrate other tables (e.g., users).

  1. Search normally (e.g., lap).
  2. Then try a UNION payload, e.g.: %' UNION SELECT id,email,0 FROM a03_users -- (dont forget your space)

Attack 3 — Blind/Time-based

id concatenation

Vulnerable idea: treat id as a free-form string and concatenate it directly. Attackers can flip logic (boolean-based) or attempt heavy expressions to infer truth via timing.

  1. Try a normal ID (e.g., 1).
  2. Then try a boolean probe like 1 OR 1=1.

Attack 4 — Second-order SQLi

store now, inject later

Vulnerable idea: accept and store a profile bio without validation, then later build a query using that stored field (e.g., to filter or join).

  1. Save a bio containing SQL fragments (try this: %' OR 1=1 -- ).
  2. Open the admin view — the later dynamic SQL breaks due to the stored payload.

Attack 5 — Stored XSS

no output encoding

Vulnerable idea: render user input directly without encoding. This embedded page runs in RAW mode to demonstrate how scripts execute.

  1. Open the demo and post <script>alert('stored')</script>.
  2. Use the page’s reflect box to try payloads like <img src=x onerror=alert(1)>.