Application Attacks

Application Attacks — Quick Reference

Attack	Root Cause	What the Attacker Gains	Primary Defense
SQL Injection	Unsanitized user input in database queries	Bypass authentication; read/modify/delete any database data	Parameterized queries (prepared statements)
Buffer Overflow	No bounds checking; input exceeds buffer size	Arbitrary code execution; crash; system access	Bounds checking (developer); DEP + ASLR (OS)
Privilege Escalation (Vertical)	Vulnerability/bug in OS or application	Higher permission level (user → admin/SYSTEM)	Patching; DEP; ASLR; least privilege
Privilege Escalation (Horizontal)	Broken access control between accounts	Access to another user's data at same privilege level	Proper access control enforcement; session isolation
CSRF	App trusts authenticated session cookies; no origin validation	Perform actions as the victim without their knowledge	Anti-CSRF tokens; SameSite cookie attribute
Directory Traversal	Web server/app uses user input in file paths without validation	Read files outside web root (configs, passwords, source code)	Input sanitization; canonical path validation; least-privilege web server account

SQL Injection — How It Works Step by Step

1. Vulnerable query identified — the application constructs a database query by concatenating user input: SELECT * FROM users WHERE username='[input]'

2. Attacker crafts malicious input — instead of a valid username, attacker enters: admin' -- (closing quote + SQL comment operator)

3. Application builds corrupted query — the constructed query becomes: SELECT * FROM users WHERE username='admin' --'; everything after -- is a SQL comment and is ignored

4. Database executes the modified query — the password check is commented out; query returns the admin user record; authentication succeeds with no password

5. Attacker escalates — with access established, attacker may use UNION-based injection to extract data from other tables, or add/modify/delete records depending on database account permissions

Parameterized Query — Why It Prevents SQLi

Vulnerable code (string concatenation):

query = "SELECT * FROM users WHERE username = '" + username + "'"

When attacker supplies admin' --, the query becomes: SELECT * FROM users WHERE username = 'admin' --' — SQL comment drops the password check.

Safe code (parameterized query):

query = "SELECT * FROM users WHERE username = ?"
db.execute(query, [username])

The database engine receives the query structure and the value separately. The ? is always treated as a data placeholder — never as SQL syntax. If the attacker supplies admin' --, the database searches for a user whose username is literally the string admin' --. No SQL command injection is possible.

Exam tip: Parameterized queries are the correct primary defense against SQL injection. Input validation and WAFs are secondary layers — they help but can be bypassed. Only parameterized queries architecturally eliminate the injection vector.

Buffer Overflow — Memory Layout

Normal operation — 64-byte buffer reserved for username input; user enters "alice" (5 bytes); buffer has 59 bytes unused; adjacent memory (return address, other variables) is untouched

Crash scenario — attacker enters 200 bytes; first 64 fill the buffer; remaining 136 overwrite adjacent memory including the return address with random garbage; application tries to return to a garbage address; crashes

Exploitable overflow — attacker crafts exactly 64+offset bytes, ending with the address of their shellcode; the return address is overwritten with precisely the value that redirects execution to attacker-controlled code; code executes — arbitrary code execution achieved

Why it's hard — the attacker must know: exact buffer size, exact offset to return address, exact address of their shellcode (or a technique to find it), and the shellcode must not contain null bytes or characters that terminate input — requires detailed knowledge of the target binary

DEP and ASLR — What They Each Address

Mitigation	What It Randomizes/Prevents	Attacker Challenge Created	Bypass Techniques
DEP (Data Execution Prevention)	Marks data memory as non-executable; CPU refuses to run code in data regions	Shellcode injected into the buffer cannot execute — "your code is in a no-execute zone"	Return-oriented programming (ROP) — chains existing executable code snippets instead of injecting new code
ASLR (Address Space Layout Randomization)	Randomizes stack, heap, library base addresses each execution	Attacker cannot hardcode the target address; address valid in testing is invalid in production	Information disclosure vulnerabilities that leak addresses; brute force on 32-bit systems (small address space)
DEP + ASLR together	Combines both: no-execute data + unpredictable addresses	Can't inject code (DEP) and can't find existing code to chain (ASLR); dramatically raises exploitation bar	Sophisticated ROP + address leak combination — requires significant binary research

Privilege Escalation — Vertical vs. Horizontal

Type	Direction	Example	Detection Clue
Vertical	Upward — lower → higher privilege	Standard user account executes CVE-2023-29336 exploit → gains SYSTEM privileges	Process spawning with higher privileges than parent; sudden admin-level activity from non-admin account
Horizontal	Lateral — same privilege level, different account	User A accesses User B's private files, emails, or account settings by exploiting broken access controls	Access log entries showing Account A reading resources owned by Account B; IDOR (Insecure Direct Object Reference) patterns in URLs

CSRF Attack Flow — Bank Transfer Scenario

1. Victim logs into bank — victim authenticates; bank's server issues session cookie; browser stores it and sends it automatically with every subsequent request to the bank's domain

2. Attacker constructs forged request — attacker knows the bank's fund transfer API: POST /transfer?to=attacker&amount=500; creates a page or email link that causes the victim's browser to make this request

3. Victim clicks attacker's link — while still logged in, victim clicks the malicious link; their browser sends the transfer request to the bank's domain; the browser automatically includes the valid session cookie

4. Bank processes the request — bank's server sees a valid session cookie; accepts the request as authenticated; executes the funds transfer to the attacker's account

5. No victim awareness — the request may complete as a background image load or redirect; victim sees nothing unusual; the attack is complete

Why Anti-CSRF Tokens Work

The anti-CSRF token breaks the attack at step 3. When the victim loaded the bank's transfer form page, the server embedded a unique, unpredictable token in the form as a hidden field:

When the victim submits the form, the token is included. The server validates the token matches the expected value for this session. Requests without a valid token are rejected.

The attacker's forged request cannot include a valid token because the attacker cannot read the victim's session page (browser same-origin policy prevents cross-origin JavaScript from reading another origin's page content). The forged request arrives without a token (or with a wrong token) and is rejected.

Why session cookies alone are insufficient: Session cookies prove identity but not intent. A token proves that the specific request originated from the actual page the server delivered to the user — not a forged cross-site request.

Directory Traversal — Log Patterns

Log Entry Pattern	Interpretation	Severity
`GET /show.asp?file=../../windows/system.ini`	Classic directory traversal attempt — two levels up from web root targeting Windows system file	High — confirms vulnerability probing
`GET /view.php?page=../../../etc/passwd`	Linux traversal attempt — three levels up targeting password file	High — confirms vulnerability probing
`GET /file?path=%2e%2e%2f%2e%2e%2fetc%2fpasswd`	URL-encoded traversal — `%2e%2e%2f` = `../`; attacker trying to bypass simple string filters	High — evasion attempt in progress
Sequential requests with incrementing `../` counts	Automated scanner probing path depth to filesystem root	High — systematic vulnerability scanning
Request for `win.ini`, `boot.ini`, `etc/shadow`, `etc/passwd` via parameter	Attacker testing for specific high-value files after establishing traversal works	Critical — active exploitation

Application Attack Concepts