Introduction

Vulnerabilities are not random bugs. They are structural failures in logic. Most major vulnerabilities stem from one root cause: Never mix Control Instructions with User Data.

If you understand this, you understand SQL Injection, XSS, and Command Injection. If you don’t, you are just memorizing lists.

---

Injection (SQL / Command)

Your database engine is a compiler. It reads a string and executes it.

• Control Plane: SELECT * FROM users WHERE name =
• Data Plane: 'Alice'

The Failure: String concatenation. query = "SELECT * FROM users WHERE name = '" + userInput + "'" If userInput is Alice' OR '1'='1, the Data Plane leaks into the Control Plane. The engine cannot distinguish between your code and the user’s input.

The Fix: Parameterized Queries. The Control Plane is compiled first. The Data Plane is passed later as a raw value. They never mix.

---

A01: Broken Access Control (Insecure Direct Object Reference)

The most commonly found vulnerability. GET /invoices/123. You change it to GET /invoices/124.

The Logic Failure: You verified Authentication (Who am I?) but forgot Authorization (Do I own invoice 124?). This is equivalent to a hotel key card that opens every room because it successfully opened the front door.

---

Server-Side Request Forgery (SSRF)

You ask the server to download an image from a URL. POST /upload?url=http://example.com/logo.png

The Attack: POST /upload?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ This is the AWS Metadata IP. If your request succeeds, the server returns its own IAM credentials to the attacker.

Why it works: The server has access to internal networks (VPC, metadata service) that the attacker should never reach. The attacker is using the server as a proxy into the internal network.

---

XSS (Cross-Site Scripting)

The browser executes any JavaScript it encounters. If you can write <script>stealCookies()</script> into a database field, every user who views that page runs your code.

The Fix: Context-Aware Encoding.

// VULNERABLE
document.body.innerHTML = userComment;

// SECURE
document.body.innerText = userComment;
// OR
div.textContent = userComment;

Defense in Depth: Content Security Policy (CSP) An HTTP header that tells the browser: “Only execute scripts from cdn.mysite.com. Block everything else — including inline scripts.”

---

Practice Exercises

Exercise 1: SQLi Polyglot (Beginner)

Scenario: A login form. Task: Why does ' OR 1=1 -- bypass the password check? Trace the boolean logic: WHERE user = '' OR True --(comment rest of line)

Exercise 2: IDOR Hunter (Intermediate)

Scenario: An API returns {"user_id": 500, "email": "me@me.com"}. Task: What happens if you change the ID in the PUT request to 501? If the server returns 200 with someone else’s data, you have found an IDOR.

Exercise 3: SSRF Bypass (Advanced)

Scenario: The server blocks 127.0.0.1. Task: How does http://2130706433/ bypass the filter (Decimal IP encoding)? How about http://localhost/ (Case-insensitive match on some parsers)?

---

Knowledge Check

1. What is the “Control Plane vs Data Plane” rule?
2. Why doesn’t input validation fix SQL Injection?
3. How does CSP prevent XSS?
4. Why is 169.254.169.254 dangerous in SSRF?
5. What is the difference between Reflected and Stored XSS?

Answers

1. Separation. Code must define the logic (Control) before seeing the input (Data).
2. Too complex. You cannot build an allowlist for every possible malicious string. Parameterization removes the root cause.
3. Whitelisting. It disables inline scripts and only allows trusted sources.
4. Cloud Metadata. It hosts sensitive credentials accessible from within AWS/GCP/Azure instances.
5. Persistence. Reflected bounces off the server (phishing link required). Stored is saved in the DB (anyone viewing that page is hit).

---

Summary

• Logic Errors > Bugs: Vulnerabilities are usually valid code doing the wrong thing.
• Trust Nothing: Every input is a potential weapon.
• Defense in Depth: WAFs, CSPs, and Least Privilege — no single control is sufficient.