CSRF Test Scenarios with PoC and Advanced Testing

1. Change password
🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change password.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

2. Change email address

🛠 Tools Required:
 - Burp Suite or OWASP ZAP
- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change email address.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

3. Change username or display name

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change username or display name.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

4. Delete user account

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to delete user account.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

5. Enable/disable two-factor authentication

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to enable/disable two-factor authentication.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

 <form action="http://vulnerable-site.com/endpoint" method="POST">
<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

6. Link/unlink social media accounts

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to link/unlink social media accounts.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:
- Log in again or refresh to see if the action was executed.
- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

7. Change security questions or recovery options

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change security questions or recovery options.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

8. Change user role (e.g., promote to admin)

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change user role (e.g., promote to admin).

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

9. Delete another user (admin privilege)

🛠 Tools Required:
 - Burp Suite or OWASP ZAP
- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to delete another user (admin privilege).

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

10. Change delivery address

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change delivery address.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

11. Make a purchase or complete checkout

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to make a purchase or complete checkout.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

12. Apply coupon or promo code

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to apply coupon or promo code.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

 <form action="http://vulnerable-site.com/endpoint" method="POST">
<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

13. Transfer money between accounts

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to transfer money between accounts.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:
- Log in again or refresh to see if the action was executed.
- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

14. Send a gift card

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to send a gift card.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

15. Cancel an order or request a refund

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to cancel an order or request a refund.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

16. Change profile photo

🛠 Tools Required:
 - Burp Suite or OWASP ZAP
- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change profile photo.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

17. Update notification settings

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to update notification settings.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

18. Change default language or timezone

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change default language or timezone.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

19. Enable/disable accessibility settings

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to enable/disable accessibility settings.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

 <form action="http://vulnerable-site.com/endpoint" method="POST">
<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

20. Opt in/out of marketing emails

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to opt in/out of marketing emails.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:
- Log in again or refresh to see if the action was executed.
- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

21. Generate or reset API token

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to generate or reset api token.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

22. Initiate password reset for another user

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to initiate password reset for another user.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

23. Change connected payment method

🛠 Tools Required:
 - Burp Suite or OWASP ZAP
- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to change connected payment method.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

24. Send messages or emails

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to send messages or emails.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.

25. Upload a file or document

🛠 Tools Required:

 - Burp Suite or OWASP ZAP

- Vulnerable web app (Juice Shop, DVWA, bWAPP)

⚙️Setup Assumptions:

- The target app has a feature to upload a file or document.

- No CSRF token or SameSite cookie protections implemented (for base test).

✅ Testing Steps:

1. Login to the application as a regular user.

2. Navigate to the feature.
3. Perform the action and capture the HTTP request in Burp Suite.
4. Reproduce the request using an HTML form.
5. Host this form on another domain (attacker’s site).
6. Auto-submit the form and verify if the action is executed without the user’s interaction.

💣 CSRF PoC (Example):

<form action="http://vulnerable-site.com/endpoint" method="POST">

<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
</form>
<script>document.forms[0].submit();</script>

🔍 Verification:

- Log in again or refresh to see if the action was executed.

- If the change occurred without user interaction, the CSRF vulnerability is present.

🔐 Advanced Case (If Security is Applied):

- Check for CSRF tokens in the form. If present, token must be valid and per-session.
- If SameSite=Lax or Strict is set on cookies, try cross-origin attack via GET or using iframe.
- Attempt Referer or Origin header manipulation if app checks them.
- If token is missing, test multiple forms to see if protection is inconsistent.