CSRF
# What is CSRF ?
CSRF, or Cross-Site Request Forgery, is a type of security
vulnerability in web applications where an attacker tricks a user
into performing actions they did not intend to do on a trusted
website where the user is authenticated.
# How does CSRF attack works ?
How CSRF Works
1. Authentication and Trust: A user logs into a legitimate
website and is authenticated, typically with a session
cookie.
2. Malicious Request: The attacker crafts a malicious request
(e.g., a form submission or URL) to the same trusted
website.
3. Exploitation: The user, while still logged in, is tricked into
executing the malicious request (by clicking a link, loading
an image, or submitting a form).
4. Unintended Actions: The trusted website processes the
request as if it came from the legitimate user, potentially
leading to actions like transferring funds, changing account
settings, or making purchases.
# How do you test for CSRF vulnerability ?
Testing for Cross-Site Request Forgery (CSRF) vulnerabilities
involves evaluating whether an application allows malicious
requests to be executed on behalf of authenticated users.
Here's how you can test for CSRF vulnerabilities:
1. Basic CSRF Test Steps
Step 1: Identify Actions to Test
Look for application functionalities that modify state (e.g.,
user profile updates, password changes, financial
transactions).
These actions are usually handled via POST or GET
requests.
Step 2: Analyze the Request
Use tools like Burp Suite, OWASP ZAP, or browser
developer tools to capture requests.
Check if there is a CSRF token (a unique parameter)
included in the request.
Step 3: Attempt CSRF
Craft a malicious HTML form or script to replicate the
request. For example:
<form action="http://victim-website.com/change_password"
method="POST">
<input type="hidden" name="password" value="newpassword123">
<input type="hidden" name="confirm_password"
value="newpassword123">
<button type="submit">Submit</button>
</form>
Host this form on a separate server or file and attempt to
execute the request as an authenticated user.
2. Testing Without a Token
If the application doesn’t use CSRF tokens:
o Submit the crafted form or malicious request.
o Check if the action is successfully executed.
3. Testing With CSRF Tokens
If tokens are present:
Inspect whether the token is:
o Static: A fixed value that doesn’t change across
requests (vulnerable).
o Predictable: Weak randomness or patterns in token
generation.
o Not Validated: Present in the request but ignored by
the server.
Example Test:
1. Log in and capture a request that includes the CSRF token.
2. Replay the request with:
o No token.
o A token from a previous session.
o A completely random token.
3. Observe whether the action succeeds or fails.
4. Testing SameSite Cookie Implementation
Check if session cookies are set with the SameSite
attribute:
o Strict: Cookies are only sent with requests originating
from the same site.
o Lax: Cookies are sent with GET requests from other
sites but not with POST.
o None or missing: Cookies can be sent in cross-origin
requests (vulnerable).
Test Case:
Attempt a cross-origin request (from another domain) and
see if the session cookie is included.
5. Using Tools for Automation
Burp Suite:
o Use the CSRF PoC generator to automatically create
proof-of-concept exploits.
o Validate CSRF token effectiveness.
OWASP ZAP:
o Look for CSRF-specific alerts when scanning the
application.
6. Validate Results
If actions succeed without proper CSRF mitigation, the
application is vulnerable.
If invalid tokens or absent headers don’t prevent state
changes, report the vulnerability.
7. Report and Recommend Fixes
Clearly explain the potential impact of CSRF vulnerabilities.
Suggest mitigations like implementing CSRF tokens,
enforcing SameSite cookies, or validating headers (e.g.,
Referer, Origin).
# Impact and Mitigation Measures .
Impact of CSRF Vulnerabilities
Cross-Site Request Forgery (CSRF) can have significant
consequences for both users and applications. The impact
depends on the context and the permissions of the targeted
user.
1. User-Level Impact
Unauthorized Actions: Attackers can force users to
perform unintended actions like:
o Transferring funds.
o Changing account details (e.g., passwords, email
addresses).
o Posting content or comments.
Data Exposure: Sensitive data might be leaked if combined
with other vulnerabilities (e.g., via a forced file download).
2. Application-Level Impact
Compromised User Trust: Exploiting CSRF can harm the
reputation of the application as users perceive it as
insecure.
Fraudulent Transactions: In financial or e-commerce
applications, attackers may execute unauthorized
transactions.
Privilege Escalation: If administrative users are targeted,
attackers can gain control over the entire application or its
configuration.
Regulatory Violations: Organizations may face fines for
failing to protect user data and prevent unauthorized
actions under laws like GDPR or PCI DSS.
3. Business-Level Impact
Financial Loss: Fraudulent transactions or data breaches
could lead to direct financial losses.
Legal Repercussions: Non-compliance with data protection
laws can lead to lawsuits or penalties.
Damage to Reputation: Loss of user trust might result in
reduced customer retention or acquisition.
Mitigation Measures for CSRF
To prevent CSRF attacks, developers should implement the
following techniques:
1. Enforce SameSite Cookies
What it Does: The SameSite attribute on cookies restricts
them from being sent with cross-origin requests.
Implementation:
o Set cookies with SameSite=Strict (or Lax for less
restrictive scenarios).
2. Validate HTTP Headers
Referer and Origin Headers:
o Check the Referer or Origin headers to ensure the
request originated from the same domain.
o If the headers are missing or invalid, reject the
request.
Limitations:
o Some browsers may not send Referer headers for
privacy reasons.
3. Use Custom Headers
Require state-changing requests (e.g., via AJAX) to include
a custom HTTP header (e.g., X-Requested-With:
XMLHttpRequest).
Browsers prevent such headers from being added in cross-
origin requests, making them a reliable defense.
4. Content Security Policy (CSP)
Implement CSP headers to mitigate other vulnerabilities
that might assist CSRF (e.g., preventing malicious scripts
from executing).
#Labs of Portswigger
