Application Attacks in Practice

Example 1 · SQL Injection Authentication Bypass

A step-by-step example of exploiting SQL injection to bypass a login form.

The vulnerable application:

A web application's login page accepts a username and password. The backend code constructs this query:

SELECT * FROM users WHERE username='[input]' AND password='[input]'

If the query returns a row, login succeeds. This is the vulnerable pattern — user input is concatenated directly into the SQL string.

Normal use:

User enters username: alice, password: hunter2. Query becomes:

SELECT * FROM users WHERE username='alice' AND password='hunter2'

If Alice exists with that password, query returns her record; login succeeds normally.

Attack — authentication bypass:

Attacker enters username: admin' --, password: anything. Query becomes:

SELECT * FROM users WHERE username='admin' --' AND password='anything'

The single quote closes the username string. The double-dash (--) is the SQL comment operator — everything after it is ignored. The password check is gone. The query returns the admin user record. Login succeeds with no password.

More destructive variants:

• ' OR '1'='1' -- — always-true condition; returns all users (first one logged in as)
• ' UNION SELECT username, password FROM users -- — if column count matches, returns all usernames and password hashes
• '; DROP TABLE users; -- — deletes the entire users table (if the DB account permits)

The parameterized fix:

stmt = db.prepare("SELECT * FROM users WHERE username=? AND password=?")
stmt.execute([username, password])

Now admin' -- is treated as a literal search string. No user with that exact username exists. Login fails. Injection is impossible.

Example 2 · Buffer Overflow — The Logic in Plain Terms

An intuitive explanation of how a buffer overflow achieves code execution.

The analogy:

Imagine a paper form with a small box for "Name" — it fits 10 characters. Under the Name box, the form has a "Next instruction" box telling the form processor what to do after reading the name. If someone writes 40 characters for their name, the overflow text crosses into the "Next instruction" box and overwrites it. Whatever was written in the overflow can now control what happens next.

In memory terms:

The CPU keeps track of where to return after a function finishes — this is stored as a "return address" on the stack, adjacent to the function's local variables (including input buffers). If a function accepts user input into a 64-byte buffer without checking the input length, an attacker who provides more than 64 bytes will overflow the buffer and start overwriting memory toward the return address.

Crash vs. exploit:

Most overflow attempts crash the application. The attacker has overwritten the return address with garbage — the CPU tries to execute instructions at a nonsensical memory address and the OS terminates the process. This is a denial of service but not code execution.

A useful overflow requires the attacker to:

1. Determine the exact number of bytes from the start of the buffer to the return address (the "offset")
2. Place attacker-controlled shellcode at a known location in memory (or use existing code via ROP)
3. Overwrite the return address with precisely the address of that shellcode

When the function finishes and the CPU reads the return address — now pointing at the attacker's shellcode — execution jumps there. The shellcode runs with the privileges of the vulnerable application.

Why DEP and ASLR help but don't fully solve it:

DEP prevents shellcode in the data buffer from executing (marked non-executable). ASLR randomizes memory addresses so the attacker can't hardcode a target address. Advanced attackers use Return-Oriented Programming (ROP) to chain existing executable code snippets and defeat DEP, and may use information disclosure bugs to leak addresses and defeat ASLR. The controls raise the bar significantly — but patching the bounds-checking bug is the only complete fix.

Example 3 · CVE-2023-29336 — Win32k Privilege Escalation in Context

How a local privilege escalation vulnerability fits into a real attack chain.

The attack scenario:

An attacker sends a phishing email to an employee at a company running unpatched Windows 10. The employee opens an attachment that installs a small RAT (Remote Access Trojan). The RAT connects back to the attacker with a low-privilege shell — it's running as the employee's standard user account. The employee's account has no admin rights.

At this point, the attacker can read the employee's files and see their browser activity. But they can't install persistent malware system-wide, can't access other users' files, can't modify security software, and can't move laterally using administrative shares. They need more privileges.

Applying CVE-2023-29336:

The attacker runs an exploit for CVE-2023-29336 through their existing shell. The exploit targets a flaw in the Win32k kernel driver — the component handling Windows' graphical subsystem. By sending a specially crafted call to the driver, the exploit triggers a memory corruption condition that allows the attacker's code to execute at kernel level with SYSTEM privileges.

In seconds, the low-privilege user shell becomes a SYSTEM shell. The attacker now has unrestricted access to every file, every process, and every account on that machine.

What SYSTEM access enables:

• Dumping all local account credentials (including cached domain credentials) using tools like Mimikatz
• Installing persistent malware that survives reboots
• Disabling endpoint protection software
• Using the machine as a pivot point to attack other systems on the network with admin credentials

What would have stopped it:

The May 2023 Patch Tuesday update containing the MS17-010 fix closed this vulnerability. A patched system — even one where the phishing RAT had successfully run — would have been immune to the privilege escalation step. The attacker would have remained limited to the low-privilege user context, significantly limiting their impact.

Example 4 · Directory Traversal — Log Analysis

Identifying and responding to directory traversal attempts in web server logs.

Log entries under review:

192.168.1.45 - - [02/May/2024:14:22:01] "GET /show.asp?file=report.pdf HTTP/1.1" 200 4521
192.168.1.45 - - [02/May/2024:14:22:14] "GET /show.asp?file=../report.pdf HTTP/1.1" 200 4521
192.168.1.45 - - [02/May/2024:14:22:18] "GET /show.asp?file=../../report.pdf HTTP/1.1" 404 –
192.168.1.45 - - [02/May/2024:14:22:22] "GET /show.asp?file=../../windows/system.ini HTTP/1.1" 200 219
192.168.1.45 - - [02/May/2024:14:22:35] "GET /show.asp?file=../../windows/win.ini HTTP/1.1" 200 92
192.168.1.45 - - [02/May/2024:14:23:01] "GET /show.asp?file=%2e%2e%2f%2e%2e%2fwindows/system32/config/SAM HTTP/1.1" 403 –

Analysis:

• Line 1: Normal request — report.pdf within the expected directory. No concern.
• Line 2: First traversal attempt — ../report.pdf. One level up. Still returned 200 — this indicates the application may not be sanitizing ../ sequences. The file exists one level up.
• Line 3: Two levels up, same filename — 404 means no file there. Attacker is probing traversal depth.
• Line 4 & 5: Successful traversal confirmed. ../../windows/system.ini returned HTTP 200 — the server served a Windows system file that should be completely outside the web root. The server is vulnerable and the attacker has confirmed it.
• Line 6: Attacker attempts to access the SAM file (Windows account hashes) using URL-encoded traversal (%2e%2e%2f = ../). Returned 403 — either blocked by ACL or the web server account doesn't have read access. Attacker is now targeting credentials.

Response actions:

1. Block IP 192.168.1.45 at the WAF immediately
2. Determine what files were accessed and what data was exposed (lines 4 and 5 are confirmed disclosures)
3. Patch the application — add canonical path validation that rejects any path resolving outside the web root
4. Review web server process privileges — restrict to read-only access on the web root only
5. Search for additional traversal attempts from other IPs in the last 30 days

Exam Scenario 1 · Attack Classification

Scenario: A penetration tester runs automated scans against a web application and records the following findings: (A) entering ' OR '1'='1' -- in the search box returns all product records including internal pricing not shown to customers; (B) setting the file parameter to ../../../../etc/passwd returns the server's password file; (C) a standard user browsing to /account?id=1042 (another user's ID) sees that user's order history; (D) clicking a crafted email link while logged into the application changes the account's email address to the attacker's without the user approving the action.

Question: Classify each finding.

Answer:
(A) SQL injection — unsanitized input in a database query returns unauthorized data.
(B) Directory traversal — ../ sequences navigate outside the web root to a system file.
(C) Horizontal privilege escalation (specifically: Insecure Direct Object Reference / IDOR) — User A accesses User B's resources at the same privilege level by manipulating a resource ID.
(D) Cross-Site Request Forgery (CSRF) — a crafted link causes the victim's authenticated browser to send an account change request the victim did not intend.

Exam Scenario 2 · Choosing Mitigations

Scenario: A security architect is reviewing an application that has three identified vulnerabilities: (1) login form is vulnerable to SQL injection; (2) an admin function constructs file download paths directly from user-supplied URL parameters; (3) the app has no validation on state-changing requests — a logged-in user who clicks a link can unknowingly trigger account changes. Recommend the most targeted mitigation for each.

Answer:
Vulnerability 1 (SQL injection login): Convert the login query to a parameterized query / prepared statement. User input is bound as a data parameter; the database never interprets it as SQL. Secondary: use a WAF rule to block common injection patterns as an additional layer.
Vulnerability 2 (user-controlled file path): Replace the user-supplied path with an indirect reference (a lookup key that maps to a server-side filename, never exposing the actual path). If the path must be constructed, canonicalize it and verify the result begins with the expected web root before serving the file. Reject any request containing ../ or URL-encoded equivalents.
Vulnerability 3 (no request origin validation): Implement anti-CSRF tokens — embed a unique, unpredictable token in every form and validate it server-side on every state-changing request. Also set SameSite=Lax or SameSite=Strict on session cookies to instruct the browser not to include them in cross-site requests.