Vulnerability Name: CSRF
LAB =
What is CSRF?
It compels the user to take actions they had not planned to take. By doing this, the attacker can partially get around the Same-Origin Policy and force the victim to carry out sensitive tasks like changing their account, making transactions, or carrying out illegal activities.
What is Same-Origin Policy?
Web browsers use a security principle called the Same-Origin Policy (SOP) to stop one domain from using another’s resources.
What is the impact of CSRF?
- The victim is forced to take unexpected actions by the assailant.
- Among the actions are password changes, email changes, and money transfers.
- The victim’s account could be completely taken over by the attacker.
- The attacker can take control of all the data and features of the application if the victim has a privileged role.
Mitigation:
- In pertinent requests, use CSRF tokens.
- Tokens need to be:
- Unpredictable and entropy-rich.
- Tied to the session of the user.
- Verify strictly before taking any action.
- Generate tokens using a cryptographically secure pseudo-random number generator (CSPRNG), optionally combined with user-specific data and hashing.
- Transmit tokens securely:
- Make use of POST forms’ hidden fields.
- Token fields should be positioned early in HTML.
- Don’t send tokens in cookies or URL query strings.
- Using custom request headers (XHR) is an optional but potentially complicated option.
- Validate tokens on the server side by comparing the request’s token with the session’s stored token.
- To manage the context of cookie usage, use Strict SameSite cookie limitations.
- Prefer SameSite=Strict; use Lax only if necessary.
- If you are not completely aware of the risks, do not disable SameSite safeguards.
Supporting Material/ References:
- https://portswigger.net/web-security/csrf
- https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
Practical Time:
Report Summary: In Burp Suite, I was able to intercept a state-changing request that was secured with a CSRF token. Only POST requests were used by the program to validate the token; other HTTP methods were not. I was able to get around the CSRF token validation and carry out the activity without a valid token by switching the request type from POST to GET while maintaining the token. This demonstrates a security flaw in which the HTTP method is used to provide CSRF protection incorrectly, enabling an attacker to get past CSRF safeguards and carry out illegal actions on the victim’s behalf.
POC
Step 1
Open the website and log in.
Step 2
- Update the email.
Step 3
- Locate the ‘change email’ request in the HTTP history, then submit it to the Repeater tab.
Step 4
- Click ‘Regenerate’ and copy the HTML after changing the request method and turning on the ‘Include auto-submit script’ option.
Step 5
Navigate to the webpage, choose the Exploit Server, then proceed to the body part of the page and paste the content.
Step 6
- Congratulations, you solved the lab!
About Author
English