Chapter 2 — Thinking like an attacker

   DEVELOPER: "The user enters their email and we send a reset link."

   ATTACKER:  What if the email is 10 MB long?
              What if it's someone else's email?
              What if it contains SQL? Or a script tag? Or a newline
                that injects an extra SMTP header?
              What if I request 10,000 resets a second?
              Is the reset token random? How long is it valid?
              Can I use it twice? Does it work after a password change?
              What does the response tell me about whether the account exists?
              Is the link sent over HTTPS? Does it leak in the Referer header?

Attack surface

Everything an attacker can reach and interact with.

   Your application's attack surface includes:

   ENTRY POINTS       every URL, API endpoint, form field, header, cookie,
                      file upload, webhook, queue message, CLI argument,
                      environment variable, config file
   DEPENDENCIES       every library, container image, base OS package,
                      CI/CD action, browser extension in your pipeline
   INFRASTRUCTURE     open ports, cloud metadata endpoints, admin panels,
                      backup buckets, DNS records, forgotten subdomains
   PEOPLE             support staff who can reset passwords, anyone who
                      can be phished, contractors, ex-employees
   PHYSICAL           laptops, USB ports, the office door

Reducing attack surface is the cheapest security work available. A deleted endpoint has no vulnerabilities. An uninstalled package can't be exploited.

Trust boundaries

The single most useful concept in this chapter. A trust boundary is any point where data crosses from a place you control to one you don't (or vice versa).

   INTERNET  --------->|  your load balancer   ------> your app -----> your DB
             boundary 1|              boundary 2|            boundary 3|

   At EVERY boundary you must ask:
      * Do I know who this is?           (authentication)
      * Are they allowed to do this?     (authorization)
      * Is this data shaped as expected?  (validation)
      * What happens if it's hostile?    (the actual question)

Validation happens at boundaries. The classic mistake is validating in the browser (inside the attacker's control) and trusting it on the server.

Rule to memorise: anything that crosses a trust boundary toward you is untrusted, no matter who sent it. Including your own frontend. Including another microservice. Including a "trusted" partner's webhook.

The attacker's process

Real attacks follow a predictable shape (this is the "kill chain"):

   1. RECON        find out what exists: subdomains, ports, versions,
                   employees on LinkedIn, leaked credentials
   2. INITIAL      get a foothold: phishing, an exposed service,
      ACCESS       a known CVE, stolen credentials
   3. EXECUTION    run code
   4. PERSISTENCE  survive a reboot or a password change
   5. PRIVILEGE    become root / admin / a service account
      ESCALATION
   6. LATERAL      move to more valuable systems
      MOVEMENT
   7. COLLECTION   find and stage the data
   8. EXFILTRATION get it out
   9. IMPACT       ransomware, destruction, fraud

Defensive value: you can break the chain at any link. Most organisations obsess over step 2 and ignore 4–8, which is where they'd actually detect a real intrusion. This model is formalised in MITRE ATT&CK (Chapter 49) — a free, extremely detailed catalogue of real techniques.

docker start juice 2>/dev/null || docker run --rm -d -p 3000:3000 --name juice bkimminich/juice-shop
sleep 15

# What's listening?
nmap -sV -p 3000 localhost

# What does the app tell us about itself?
curl -sI http://localhost:3000 | head -20
curl -s http://localhost:3000 | grep -oE 'src="[^"]+"' | head -20