EXERCISE 1 — SSRF vs CSRF + 3 attack targets ============================================= SSRF VS CSRF (who makes the request + where it comes from): CSRF (Cross-Site Request Forgery): WHO MAKES THE REQUEST: the user's web browser. HOW: attacker tricks the user into visiting a malicious page that embeds a request (via
, , fetch(), XHR) to the target site. WHERE THE REQUEST COMES FROM: the user's IP address, the user's browser context, the user's session/cookies. EXAMPLE: attacker's site contains . User visits attacker's site. User's browser (with valid bank session cookie) sends the request to bank.example.com. Bank thinks the user authorized the transfer. WHAT ATTACKER GAINS: ability to perform actions as the user (transfer money, change password, post content) — but only to resources the browser can access from the attacker's site (public, cross-origin-allowed). BLOCKED BY: same-site cookies, CSRF tokens, origin checks, not accepting requests from different origins. SSRF (Server-Side Request Forgery): WHO MAKES THE REQUEST: the server (web app's backend). HOW: attacker provides a URL parameter to a feature that fetches/processes URLs (e.g., "preview this image," "webhook callback," "download from URL"). WHERE THE REQUEST COMES FROM: the server's IP address, the server's network privileges, services the server can reach (internal APIs, databases, metadata services). EXAMPLE: attacker provides URL http://localhost:27017 (MongoDB) to a "preview image" feature. Server makes a request to localhost:27017 (the internal MongoDB). Server can access internal services the browser never could. WHAT ATTACKER GAINS: ability to access internal resources (databases, admin APIs, cloud metadata, internal dashboards) — resources NOT intended for external/public access. BLOCKED BY: URL validation (allowlist expected domains, block private IPs), network filtering (firewall rules preventing outbound to internal services), least privilege (server can't reach internal services). KEY DIFFERENCE: CSRF: attacker leverages user's session/privileges (user's browser, user's IP). SSRF: attacker leverages server's privileges (server's IP, server's network access). In other words: CSRF = "make the user do something they shouldn't." SSRF = "make the server reach something it shouldn't be able to reach." --- 3 SSRF ATTACK TARGETS (what each exposes): TARGET 1: AWS METADATA SERVICE (169.254.169.254) What it is: AWS's internal metadata endpoint. Every EC2 instance can request http://169.254.169.254/latest/meta-data/ and learn about itself (instance ID, region, IAM role, temporary credentials). Attack payload: http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role What it exposes: AWS STS temporary credentials (access key, secret key, session token). With these, attacker can assume the IAM role and access ANY AWS service/resource the role is permitted to use (S3 buckets, RDS databases, Lambda functions, etc.). Why it's dangerous: instance credentials are POWERFUL (they grant all the permissions of that role) and are only meant to be accessed by code RUNNING ON the instance. Exposing them via SSRF lets an external attacker impersonate the instance. TARGET 2: LOCALHOST DATABASE (e.g., http://localhost:27017 for MongoDB) What it is: a database service (MongoDB, PostgreSQL, MySQL, Redis) running on the same server or a connected internal service, listening on localhost or a private IP. Attack payload: http://localhost:27017 or http://192.168.1.10:5432 What it exposes: if the database is unprotected (no auth, default creds, or auth misconfigured), the attacker can: - Read database contents (customer data, secrets, configs). - Write/modify data (inject records, alter transactions). - Execute commands (some databases allow file write/command execution). Why it's dangerous: databases are high-value targets and are typically NOT exposed to the internet (they're internal). They're protected by the assumption that only trusted internal services access them. SSRF breaks that assumption. TARGET 3: INTERNAL API (e.g., http://internal-api.corp/admin/users) What it is: an API endpoint on the internal network, accessible only from internal IPs. Examples: internal billing API, internal customer DB, internal admin panel, internal analytics service. Attack payload: http://internal-api.corp/admin/users/delete?id=1234 or http://10.0.0.5:8080/admin/status What it exposes: if the internal API trusts requests from internal IPs (or lacks authentication), the attacker can: - Enumerate internal services (what APIs exist?). - Perform admin actions (delete users, modify config, trigger internal processes). - Steal internal data (query the API for sensitive info). Why it's dangerous: internal APIs assume only trusted internal code accesses them. They often lack the security hardening of public APIs (no rate limiting, no auth, no input validation). SSRF bypasses the "internal only" firewall rule. --- SUMMARY TABLE: Target | What It Is | Exposes | Risk Level --------------------|------------------------|------------------------------|---------- AWS Metadata | Cloud instance metadata | IAM credentials + secrets | CRITICAL Localhost Database | Internal DB service | Full DB (read/write/exec) | CRITICAL Internal API | Internal service API | Admin actions, internal data | HIGH Private IPs | Enumeration of network | Service discovery, ports | MEDIUM File URLs | Filesystem access | /etc/passwd, configs | HIGH Gopher/Dict | Legacy protocol access | SMTP, SSH, other ports | MEDIUM --- ONE-LINE TAKEAWAY: CSRF forges browser requests (using user's session); SSRF forges server requests (using server's network privilege) to access internal resources (metadata, DBs, internal APIs).