Privilege Escalation and the Application Attack Family

5.1.A.2–3Concept

Privilege Escalation and Weak Access Controls

Most systems distinguish standard users from administrative users — admins can access nearly any file or setting, while standard accounts are limited. That distinction only protects anything if it's actually enforced.

Privilege escalation happens when a standard user is unnecessarily given administrative rights. If an adversary compromises that one account — through any method from earlier units, phishing included — they inherit full administrative access, not just the limited access a standard account should have had.

Weak access control settings create a related but distinct problem: when file and folder permissions are configured too loosely, many users can view or even edit files they have no real reason to touch — widening the pool of accounts an adversary could compromise to reach the same sensitive data.

🔑Neither of these requires a sophisticated exploit. Both are entirely about configuration — which makes them common, and makes tightening permissions one of the highest-value, lowest-cost security improvements available.

5.1.B.2–4Attack

SQL Injection

Many applications take open-ended user input, then use it to query a database using SQL (Structured Query Language). If that input isn't checked against what's actually expected — a process called data validation — an adversary can type SQL commands directly into the input field instead of the data the field expects.

Username field: admin' OR '1'='1

A crafted input like this can trick a poorly-built login query into treating the condition as always true — returning data it shouldn't (a confidentiality breach), or letting the adversary modify or delete database records (an integrity breach).

⚠️The defense is input sanitization / data validation — checking that user input actually matches what's expected (a number field only accepts numbers) and rejecting anything that doesn't, before it ever reaches the database.

5.1.B.5–6Attack

Cross-Site Scripting (XSS)

Websites commonly use JavaScript to create dynamic content — but because that code runs inside the visitor's own browser, it can potentially access sensitive data stored there: usernames, passwords, session tokens. A cross-site scripting (XSS) attack injects malicious code into a website that a victim's browser then executes as if it were legitimate.

🎭 Reflected vs. Stored XSS

The malicious code is embedded in a link. It only runs when a specific victim clicks that specific link — the attack is 'reflected' back at whoever follows it, one target at a time.

💡The distinction matters for scope: reflected XSS needs a specific victim to click a specific link, while stored XSS silently affects every single visitor to a compromised page — a much larger blast radius from one successful attack.

5.1.B.7–8Attack

Buffer Overflow

User input gets written to a buffer — a fixed-size section of memory reserved for it. If the input is larger than the buffer, the excess spills into adjacent memory it was never meant to occupy.

💾 Buffer Overflow — toggle the input size

The buffer has room for 5 units of data (green), with 3 units of unused allocated space beyond it. Normal input fits entirely inside the buffer.

⚠️Depending on exactly what that adjacent memory holds, a buffer overflow can simply crash the program — or, in a worse case, let an adversary execute code outside the program's intended security boundaries, effectively performing unauthorized actions on the system.

5.1.B.9–10Attack

Directory Traversal

Web servers store their files in specific directories. When your browser requests a page or image, it sends an HTTP GET request pointing to a file somewhere in that structure. A directory traversal attack manipulates that request to reach files well outside the folder it was supposed to stay in.

ExampleGuided Example — Reading the Traversal Path

A web server stores product images at /var/www/images/. An adversary requests: /var/www/images/../../../etc/passwd

Step 1 — Read one .. at a time

Each ../ moves one directory up the file tree. Starting from /var/www/images/, three consecutive ../ climbs all the way up to the root directory.

← Back to Activity 2.2.2 Next: Activity 2.2.3 →Server Analysis.