This chapter covers Cross-Site Request Forgery (CSRF) and Server-Side Request Forgery (SSRF) attacks, two critical web application vulnerabilities that appear frequently on the PT0-002 exam. Understanding the mechanisms, differences, and exploitation techniques is essential for penetration testers. Approximately 5-8% of exam questions directly assess your knowledge of CSRF and SSRF, including identification, exploitation, and mitigation strategies.
Jump to a section
Imagine a bank where customers can request money transfers by filling out a form and handing it to a teller. The teller processes the request and executes the transfer. A CSRF attack is like an attacker mailing a pre-filled transfer form to a customer, tricking them into handing it to the teller. The teller sees the customer's signature and processes the transfer, thinking the customer authorized it. The attacker never talks to the teller directly; they exploit the customer's authenticated session. Now consider a different scenario: the bank has a secretary who handles internal requests. An SSRF attack is like an attacker calling the secretary and pretending to be an employee, asking the secretary to fetch a file from the internal server. The secretary, trusting the caller, retrieves the file and sends it to the attacker. The attacker never had direct access to the internal server; they used the secretary's access. In CSRF, the victim's browser is tricked into sending a request; in SSRF, the server itself is tricked into making a request to internal resources.
What is CSRF?
Cross-Site Request Forgery (CSRF, also known as XSRF) is an attack that forces an authenticated user to execute unwanted actions on a web application in which they are currently authenticated. The attacker crafts a malicious request that appears legitimate to the server because it includes the user's session cookies or authentication tokens. The victim's browser automatically attaches these credentials when making the request, so the server processes it as if the user intended it.
CSRF exploits the trust that a web application has in the user's browser. Unlike cross-site scripting (XSS), which exploits the user's trust in a site, CSRF exploits the site's trust in the user's authenticated session.
How CSRF Works
The attack typically follows these steps: 1. The user logs into a vulnerable web application (e.g., a banking site) and obtains a session cookie. 2. The attacker crafts a malicious HTML page or email containing a request to the vulnerable application (e.g., a money transfer). 3. The victim visits the malicious page while still authenticated to the vulnerable application. 4. The victim's browser sends the forged request, including the session cookie, to the vulnerable application. 5. The server processes the request as valid and executes the action (e.g., transfers money).
Key Components of CSRF
Same-Origin Policy (SOP): Browsers enforce SOP, which prevents a malicious site from reading responses from a different origin. However, SOP does not prevent the sending of requests. CSRF exploits this loophole: the attacker can send a request but cannot read the response.
Session Cookies: Cookies are automatically sent by the browser for the target domain, regardless of the origin of the request. This is the core vulnerability.
HTTP Methods: CSRF attacks often use GET requests because they can be embedded easily in <img>, <iframe>, or <a> tags. POST requests can be forged using HTML forms with auto-submitting JavaScript.
CSRF Defenses
CSRF Tokens: A unique, unpredictable token is embedded in each form or request. The server validates the token before processing the request. The attacker cannot guess or obtain the token from the victim's session.
SameSite Cookies: The SameSite attribute on cookies prevents the browser from sending the cookie along with cross-site requests. SameSite=Lax (default in modern browsers) blocks most CSRF attacks, while SameSite=Strict provides stronger protection.
Referer/Origin Header Validation: The server checks the Referer or Origin header to ensure the request originated from the same site. However, these headers can be spoofed in some cases.
Custom Headers: Requiring a custom header (e.g., X-Requested-With: XMLHttpRequest) that cannot be set cross-origin without JavaScript can block simple CSRF attacks.
What is SSRF?
Server-Side Request Forgery (SSRF) is an attack where the attacker abuses a server-side application to make HTTP requests to internal or external resources that the server can access. The attacker typically controls the URL or endpoint that the server fetches, allowing them to interact with internal services, read files, or perform port scans.
SSRF exploits the trust that the server has in itself or its internal network. The attacker leverages the server's ability to make requests to resources that are not directly accessible from the external network.
How SSRF Works
The web application accepts a user-supplied URL (e.g., for fetching a remote resource, processing webhooks, or importing data).
The attacker provides a URL pointing to an internal service (e.g., http://localhost:8080/admin or http://169.254.169.254/latest/meta-data/ for cloud metadata).
The server makes a request to that URL, potentially accessing sensitive data or performing actions on internal systems.
The attacker receives the response (if the application returns it) or can observe side effects (e.g., timing differences, error messages).
Key Components of SSRF
Internal Network Access: The server can access internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x) and localhost (127.0.0.1).
Cloud Metadata Endpoints: Cloud providers expose metadata services at specific IPs (e.g., AWS: 169.254.169.254, Azure: 169.254.169.254, GCP: metadata.google.internal). SSRF can be used to retrieve instance credentials.
Protocols: SSRF is not limited to HTTP. Attackers can use file://, dict://, gopher://, or ftp:// schemas to interact with other services or read local files.
Blind SSRF: When the response is not returned to the attacker, they may use out-of-band techniques (e.g., DNS lookups, HTTP callbacks) to confirm the request was made.
SSRF Defenses
Allowlist: Only permit requests to a predefined list of trusted domains or IPs. This is the most effective defense.
Denylist: Block known malicious IPs (e.g., 127.0.0.1, 169.254.169.254). However, denylists are often bypassed using redirects, DNS rebinding, or alternative representations (e.g., 0.0.0.0, [::1]).
Disable Unnecessary Protocols: Restrict the application to use only HTTP/HTTPS and disable other schemas.
Network Segmentation: Isolate the application server from sensitive internal services using firewalls or network policies.
Input Validation: Validate and sanitize user-supplied URLs to prevent manipulation.
Interaction with Related Technologies
XSS vs. CSRF: XSS can bypass CSRF defenses by stealing tokens or executing actions on behalf of the user. CSRF alone cannot read responses, but XSS can.
SSRF and Cloud Exploitation: SSRF is a common vector for compromising cloud instances by accessing metadata services that provide temporary credentials.
SSRF and Internal Service Discovery: Attackers use SSRF to scan internal networks, identify running services, and exploit vulnerabilities in internal applications (e.g., Redis, Elasticsearch).
Identify vulnerable functionality
The first step in exploiting CSRF or SSRF is to identify entry points. For CSRF, look for state-changing actions (e.g., password change, money transfer) that lack CSRF tokens or other protections. For SSRF, look for features that fetch remote resources, such as URL imports, webhook handlers, or image download functionality. Use a proxy (e.g., Burp Suite) to intercept requests and analyze parameters. Check if the application uses GET requests for sensitive actions, which are easier to forge. For SSRF, test by providing internal IPs (e.g., 127.0.0.1) and observe if the server responds or times out.
Craft a malicious request
For CSRF, create an HTML page that automatically submits a form or loads an image that triggers the action. Example: `<img src="http://bank.com/transfer?amount=1000&to=attacker" />`. For POST-based CSRF, use a form with auto-submit JavaScript. For SSRF, modify the URL parameter to point to internal resources. Example: `http://vulnapp.com/fetch?url=http://169.254.169.254/latest/meta-data/`. Use encoding or alternate representations (e.g., `127.1` instead of `127.0.0.1`) to bypass denylists.
Deliver the exploit to the victim
For CSRF, the attacker must trick the authenticated victim into visiting the malicious page. This can be done via phishing emails, social media posts, or embedding the payload on a popular site (if XSS is also present). The victim must be logged into the target application at the time of visiting the malicious page. For SSRF, the attacker directly sends the malicious request to the vulnerable server, often through the application's own interface. No victim interaction is required beyond the initial request.
Execute the attack and observe results
When the victim's browser loads the CSRF payload, it automatically sends the forged request with the victim's cookies. The server processes the request and performs the action. The attacker may not see the response due to SOP, but the action is executed. For SSRF, the server makes the request to the internal resource. If the application returns the response, the attacker can read sensitive data. If blind, the attacker uses out-of-band techniques (e.g., DNS log) to confirm the request reached the target.
Escalate or pivot internally
After confirming CSRF, the attacker can chain it with other vulnerabilities (e.g., XSS) to bypass CSRF tokens or perform more actions. For SSRF, once internal access is gained, the attacker can scan for other services, exploit internal applications (e.g., Redis, Memcached), or access cloud metadata to steal credentials. SSRF often leads to full internal network compromise if the server has broad access.
In a typical enterprise penetration test, CSRF and SSRF are commonly found in legacy applications or those with insufficient security controls. For example, a large financial institution's online banking portal might have a money transfer feature that uses GET requests without CSRF tokens. A pentester can craft a simple HTML email that, when opened by a logged-in user, transfers funds to the attacker's account. The fix involves implementing CSRF tokens and switching to POST requests with proper validation.
Another scenario is a cloud-native application that allows users to import data from URLs. A pentester can exploit SSRF to access the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/) and retrieve temporary IAM credentials. With these credentials, the attacker can access S3 buckets, launch instances, or escalate privileges. The defense is to restrict outbound requests from the application server using a firewall and validate URLs against an allowlist.
A common misconfiguration is using a denylist for SSRF protection. For instance, blocking 127.0.0.1 but forgetting to block 0.0.0.0, [::1], or DNS rebinding attacks. In one engagement, a pentester bypassed the denylist by using http://localhost:8080 which resolved to 127.0.0.1 but wasn't explicitly blocked. The lesson is that allowlists are far more secure than denylists.
Performance considerations: SSRF attacks can cause internal services to be overwhelmed if the attacker sends many requests. In production, rate limiting and proper input validation are necessary. Also, cloud metadata endpoints are often protected by network policies, but if the application server has unrestricted outbound access, SSRF can be devastating.
The PT0-002 exam tests CSRF and SSRF under Objective 3.2: "Given a scenario, analyze attacks and exploits." You must be able to identify these attacks from logs, code snippets, or descriptions. Common wrong answers include confusing CSRF with XSS (remember: CSRF exploits site trust in user's browser; XSS exploits user trust in site). Another trap is thinking that HTTPS prevents CSRF (it does not; cookies are still sent). For SSRF, a common mistake is assuming that only HTTP requests are possible; remember that SSRF can use file://, gopher://, etc.
Specific numbers: The AWS metadata IP is 169.254.169.254. The SameSite cookie attribute values are Strict, Lax, and None. SameSite=Lax is the default in modern browsers and prevents CSRF for most state-changing requests except top-level navigations. The Origin header is more reliable than Referer for CSRF detection.
Edge cases: CSRF can still occur with SameSite=Lax if the attack uses a top-level navigation (e.g., <a> tag). SSRF can be blind; the exam may present a scenario where no response is returned, but out-of-band detection (e.g., DNS query) confirms the request. Also, SSRF can be used to attack internal services that speak non-HTTP protocols (e.g., Redis via gopher://).
To eliminate wrong answers, focus on the mechanism: if the attack involves the victim's browser sending a request with cookies, it's CSRF. If the attack involves the server making a request to an internal resource, it's SSRF. Check for keywords like "authenticated session," "forged request," or "internal network."
CSRF forces an authenticated user to execute unwanted actions via forged requests.
CSRF exploits the automatic inclusion of cookies by the browser.
SSRF forces a server to make requests to internal or external resources.
The AWS metadata endpoint is at 169.254.169.254; Azure and GCP use similar IPs.
SameSite cookie attribute (Lax/Strict) is a strong CSRF defense.
Allowlists are more effective than denylists for SSRF protection.
CSRF can be blind (no response) but still successful; SSRF can be blind but detectable via out-of-band.
XSS can bypass CSRF defenses by stealing tokens or executing actions.
SSRF can use protocols other than HTTP (e.g., file://, gopher://).
Always test for CSRF and SSRF in web application penetration tests.
These come up on the exam all the time. Here's how to tell them apart.
CSRF
Exploits the trust a site has in the user's browser.
Requires the victim to be authenticated and visit a malicious page.
Attack is executed by the victim's browser.
Typically targets state-changing actions (e.g., transfer, change password).
Defenses include CSRF tokens, SameSite cookies, and Referer validation.
SSRF
Exploits the trust a server has in itself or its internal network.
Does not require victim interaction beyond the initial request to the vulnerable server.
Attack is executed by the vulnerable server.
Typically targets internal resources (e.g., cloud metadata, internal services).
Defenses include allowlists, disabling unnecessary protocols, and network segmentation.
Mistake
CSRF and XSS are the same attack.
Correct
CSRF forces the victim's browser to send a forged request; XSS injects scripts into a trusted site. CSRF exploits the site's trust in the browser; XSS exploits the user's trust in the site.
Mistake
HTTPS prevents CSRF attacks.
Correct
HTTPS encrypts the traffic but does not prevent the browser from sending cookies with cross-origin requests. CSRF works over HTTPS just as well.
Mistake
SSRF only works with HTTP.
Correct
SSRF can use various protocols like file://, gopher://, dict://, and ftp:// to interact with internal services or read local files.
Mistake
Using a denylist for SSRF is sufficient.
Correct
Denylists are easily bypassed using alternate IP representations (e.g., 0.0.0.0, [::1]), DNS rebinding, or redirects. Allowlists are far more secure.
Mistake
CSRF tokens make an application completely immune to CSRF.
Correct
If the application also has XSS, an attacker can steal the CSRF token and forge requests. CSRF tokens must be properly validated and tied to the user's session.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CSRF (Cross-Site Request Forgery) forces a user's browser to send a forged request to a site where they are authenticated, exploiting the site's trust in the browser. XSS (Cross-Site Scripting) injects malicious scripts into a trusted site, exploiting the user's trust in the site. CSRF cannot read responses; XSS can. XSS can be used to bypass CSRF defenses.
Use a proxy like Burp Suite to intercept requests. Look for state-changing actions (e.g., password change, transfer) that lack CSRF tokens or use GET requests. Try to forge a request from a different origin and see if it is accepted. Tools like Burp's CSRF PoC generator can help create proof-of-concept exploits.
The AWS metadata endpoint is at http://169.254.169.254/latest/meta-data/. It provides instance metadata including IAM role credentials. SSRF attacks targeting this endpoint can retrieve temporary credentials, allowing the attacker to access AWS resources. Azure and GCP have similar endpoints.
No. HTTPS encrypts traffic between the browser and server but does not prevent the browser from sending cookies with cross-origin requests. CSRF works over HTTPS. Proper defenses are CSRF tokens, SameSite cookies, or custom headers.
Common bypasses include using alternative IP representations (e.g., 0.0.0.0, [::1], decimal IPs), DNS rebinding, redirects (if the server follows them), and using different protocols (e.g., file://, gopher://). Also, using cloud metadata endpoints with different URLs (e.g., metadata.google.internal).
The SameSite attribute tells the browser to only send cookies with requests originating from the same site. SameSite=Lax (default) sends cookies for top-level navigations but not for cross-origin subrequests. SameSite=Strict blocks cookies for all cross-origin requests. This prevents the browser from attaching session cookies to forged requests.
Blind SSRF occurs when the server makes a request to an internal resource but does not return the response to the attacker. Detection uses out-of-band techniques such as setting up a DNS server or HTTP listener. If the server performs a DNS lookup or connects to the attacker's server, the attack is confirmed.
You've just covered CSRF and SSRF Attacks — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?