Information Security
CSRF, SSRF, CORS
2019. Capital One. One of the largest US banks. An attacker finds a URL-fetch feature in a cloud application and passes the AWS metadata service address: http://169.254.169.254/latest/meta-data/iam/security-credentials/. The server dutifully makes the request, receives IAM keys, and returns the result. 106 million records leak. Fine: $80 million. Root cause: SSRF. One missing IP validation check cost a bank nine figures.
- **Capital One 2019**: SSRF via a WAF function provided IAM credentials and exposed 106 million records - the first large-scale SSRF against cloud infrastructure.
- **Linksys CSRF 2008**: malicious websites changed DNS settings on 200,000 routers via CSRF without a single deliberate user action.
- **Facebook SSRF 2016**: $31,500 bug bounty for an SSRF that allowed reading internal services - paid for ethical disclosure.
CSRF: Forged Requests via Automatic Cookies
CSRF exploits the fact that browsers automatically attach cookies to every request. If a user is logged into bank.com and visits evil.com, a form on evil.com can submit a POST request to bank.com with a valid session cookie. The server cannot distinguish a legitimate user action from a forged one - both carry the same cookie.
SameSite=Lax is now the default in Chrome, Firefox, and Safari. This significantly reduced CSRF prevalence for modern applications. However, legacy systems, custom auth protocols, and mobile WebViews remain vulnerable. CSRF tokens remain necessary for any state-changing action in systems that use cookies for authentication.
A site uses JWT stored in localStorage (not in a cookie) for authorization. Is it vulnerable to CSRF?
Same-Origin Policy: The Browser's Core Security Boundary
Same-Origin Policy (SOP) is the browser's fundamental security mechanism. JavaScript on evil.com cannot read responses from bank.com. Without SOP, any website could read Gmail, initiate transfers, or steal cookies. SOP defines 'origin' as the combination of protocol, domain, and port - all three must match.
SOP blocks reading, not sending. CSRF is possible precisely because SOP does not prevent the browser from sending cross-origin POST requests. Only reading the response is blocked. For state-changing operations this is enough for attackers - the response is irrelevant, only the server-side action matters.
JavaScript on https://app.example.com makes a fetch() to https://api.example.com/data. Does SOP block this request?
SSRF: The Server as an Attacker's Proxy
SSRF is an attack where the server makes an HTTP request to an arbitrary address supplied by a user. The server operates from inside the network and has access to internal services, cloud metadata APIs, and localhost. SSRF entered the OWASP Top 10 in 2021 as a new entry - driven by cloud adoption.
DNS Rebinding bypasses IP-based SSRF filters: on the first DNS lookup, attacker.com returns a public IP (passes the allowlist check). On the second lookup after TTL expiry, it returns 169.254.169.254. The server cached the first DNS response as safe, but the second fetch reaches the metadata service. Mitigation: resolve DNS once, validate the resulting IP, and use that IP for the actual request.
An AWS application accepts a URL to fetch an image. The developer added a check: the URL must start with https://. Is this sufficient protection against SSRF?
CORS: Controlled Relaxation of Same-Origin Policy
SOP blocks cross-origin requests by default. But real architectures require frontends on app.example.com to call APIs on api.example.com. CORS (Cross-Origin Resource Sharing) lets the server explicitly permit specific origins via HTTP headers. The browser enforces these permissions.
CORS does not protect the server - it protects the user's browser. curl, Postman, and Burp Suite ignore CORS headers entirely. CORS tells the browser whether JavaScript on one site may read a response from another. Server-side protection against unauthorized access requires authentication and authorization checks, not CORS.
A developer configures CORS: Access-Control-Allow-Origin: *. What is the problem?
Key Ideas
- **CSRF**: browser auto-sends cookies on cross-origin requests. Defense: CSRF tokens (unpredictable per-session value) + SameSite=Lax/Strict cookies.
- **SOP**: blocks reading cross-origin responses (not sending). Same-origin = protocol + domain + port must all match. Subdomains are different origins.
- **SSRF**: server fetches a URL from user input and reaches internal services or cloud metadata. Defense: validate the resolved IP against private ranges; use an egress allowlist.
- **CORS**: controlled relaxation of SOP via server headers. CORS protects the browser user, not the server. Never mirror the Origin header without validation.
Related Topics
CSRF, SSRF, and CORS connect to the surrounding web security landscape:
- SQL Injection — The previous class of web attacks - injection into database queries rather than request forgery.
- XSS — XSS is often used to bypass SameSite cookies and amplify CSRF attacks.
- API Security — CORS policy and CSRF protection are critical for REST and GraphQL APIs.
Вопросы для размышления
- A GraphQL API on api.example.com needs to be called from a React app on app.example.com. How would you configure CORS correctly, including handling credentials and preflight caching?
- An image hosting service accepts URLs and downloads images server-side. Design a defense against SSRF that allows legitimate external URLs but blocks all internal network access.
- A legacy application uses cookie-based sessions and cannot add CSRF tokens without a full rewrite. What is the fastest partial mitigation that provides meaningful protection?