Scribd
Upload
3 views

CSRF task 9

CSRF

Uploaded by

anurag.21bcan254
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
3 views

CSRF task 9

CSRF

Uploaded by

anurag.21bcan254
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 11

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

You might also like