Introduction

Vulnerabilities are not random bugs. They are structural failures in logic. Every major vulnerability stems from violating one fundamental law of physics in computing: 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.

---

The Physics: 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 leak into the Control Plane. The Engine cannot distinguish between your code and the user’s input.

The Fix: Parameterized Queries. The Control Plane is sent first (compiled). The Data Plane is sent later as a raw value. They never touch.

---

A01: Broken Access Control (Insecure Direct Object Reference)

The most common vulnerability. GET /invoices/123. I change it to GET /invoices/124.

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

---

Deep Dive: 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 Admin Keys to the attacker.

Physics: Bridging. The server has access to internal networks (Control Plane) that the User (Data Plane) should never reach.

---

Code: XSS (Cross-Site Scripting)

The browser executes any JavaScript it sees. If I can write <script>stealCookies()</script> into your database, every user who views that page executes my 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) A header that tells the browser: “Only execute scripts from cdn.mysite.com. Block everything else.”

---

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 it works, 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)? OR http://Localhost (Case sensitivity)?

---

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 validate 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 on AWS/GCP/Azure instances.
5. Persistence. Reflected bounces off the server (phishing link). Stored is saved in the DB (forum post).

---

Summary

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

---