Client-Side Request Forgery

Client-Side Request Forgery (CSRF)

Definition:

CSRF is an attack where an attacker tricks a victim into performing actions on their behalf on a web application where the victim is authenticated. The victim's browser is deceived into executing an undesired action in a site where they're authenticated and have an active session. Essentially, it's a malicious third-party exploit of a trusted site.

Key Points:

• Unlike Cross-Site Scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in the user's browser.

• For a CSRF attack to be successful, the victim must be authenticated and have an active session.

Attack Scenario:

1. The victim logs into example.com, which uses cookies for session management.

2. Without logging out, the victim visits a malicious website.

3. The malicious website contains a link, button, or auto-executing script (often embedded within an <img> tag to load an image) which makes a request to example.com using the victim’s credentials.

4. example.com receives the request, thinks it's legitimate (since it's coming with a valid session cookie), and performs the undesired action.

Example Attack:

html

<!-- Malicious website content -->
<img src="http://example.com/transferFunds?amount=1000&destinationAccount=attackerAccount" width="0" height="0" />

In this example, if the victim has an active session on example.com, simply visiting the malicious site will inadvertently send $1000 to the attacker's account.

Common Targets:

• Changing account settings

• Unauthorized fund transfers

• Password changes

• Purchases

Mitigation:

1. Anti-CSRF Tokens:

   • Use stateful session tokens or stateless tokens (e.g., JWT tokens with proper validation).

   • For every session, a unique token is generated and embedded in forms or AJAX requests.

   • The server validates this token before processing any request.

   • Attackers can't predict this token and hence can't forge the request.

   Example:

   html

• <input type="hidden" name="csrf_token" value="randomToken12345">

• Check Referer Headers:

  • Ensure the request came from a trusted source.

  • Be cautious: headers can be spoofed in some contexts.

• Use SameSite Cookie Attribute:

  • This attribute allows servers to assert that a cookie ought not to be sent along with cross-site requests.

  • Values: Strict (never sent with cross-site requests) or Lax (sent with top-level navigations).

  Example:

  javascript

1. Set-Cookie: session=value; SameSite=Strict;

2. Require Re-authentication:

   • For sensitive actions, ask users to re-enter their password or use 2FA.

3. Custom HTTP Headers:

   • JS can be used to add custom headers, and because of the same-origin policy, only your website can modify its own headers.

   • Check for the custom header in every request on the server-side.

Detection:

1. Manual Testing:

   • Perform actions while authenticated and capture the requests.

   • Replay them without any session cookies. If the action still goes through, it's a CSRF vulnerability.

2. Automated Tools:

   • Tools like OWASP ZAP or Burp Suite can be used to detect CSRF vulnerabilities.

Miscellaneous Notes:

• Always keep libraries/frameworks updated; many modern frameworks come with built-in CSRF protections.

• CSRF mainly targets state-changing requests, not data theft since the attacker doesn't see the response.

Conclusion:

CSRF is a prominent web vulnerability that exploits the trust web applications have in the user's browser. Implementing multiple layers of security checks like using anti-CSRF tokens, validating the referer headers, and requiring re-authentication for sensitive actions can mitigate the risk of CSRF attacks. Always be cautious and ensure that any action that has a side effect (e.g., data change, transaction) on the server is properly protected against CSRF.