CSRF – Cross-Site Request Forgery

CSRF (Cross-Site Request Forgery), is a type of web application vulnerability where an attacker can trick a logged-in user into unknowingly performing an action, such as deleting data.

CSRF exploits the fact that the browser automatically sends with an HTTP request cookies to the web application being attacked.

What is CSRF?

CSRF exploits the fact that the browser automatically sends, for example, cookies with a request to the web.

For example, a user is logged in to:

https://example.cz

The attacker creates a page that attempts to send a request to this website:

<form action="https://example.cz/change-email" method="POST"> <input type="hidden" name="email" value="utocnik@example.com"> </form> <script> document.forms[0].submit(); </script>

If the application does not have CSRF protection, the browser can automatically attach an authentication cookie to the request. The server can then consider the request a legitimate user action.

Why is CSRF dangerous?

It depends on what operations the application allows. For example, an attacker can:

change email or other account settings,
change password, if the application allows such a change without further verification,
submit a form on behalf of the victim,
make a purchase or other financial operation,
change permissions or account settings.

CSRF is particularly problematic for requests that change the application's state.

How to properly address CSRF?

1. Use a CSRF token

The most common protection is a random CSRF token that the server inserts into the form and then verifies it when processing the request.

<form action="/change-email" method="POST"> <input type="hidden" name="csrf_token" value="RANDOM_TOKEN"> <input type="email" name="email"> <button type="submit">Change email</button> </form>

The server must verify that the csrf_token matches the token stored for the given session. The token must be sufficiently random and unpredictable.

2. Set SameSite for cookies

Authentication cookies should have the SameSite attribute appropriately set, for example:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

SameSite=Lax or, depending on the specific application, SameSite=Strict can significantly limit the possibilities of a CSRF attack.

3. Check Origin or Referer

For sensitive requests, the server can check the Origin and potentially Referer headers to verify that the request genuinely originates from the expected website.

4. Do not change state using GET

Operations that modify data should not use GET.

Bad:

GET /delete-account

Better:

POST /delete-account

However, simply using POST is not sufficient protection against CSRF. Even a POST request can be crafted from an external page. Therefore, it is advisable to use a CSRF token and other suitable protections.

Most important rule

For state-changing requests, use a CSRF token, correctly configured cookies (especially SameSite), and, if necessary, Origin checking.

If you use a modern framework such as Django, Laravel, Symfony, Spring, ASP.NET, or Rails, it usually has built-in CSRF protection. In such cases, it is best to use the mechanism provided by the framework and not invent your own implementation.

Whether or not you care about the security of your application, it is definitely necessary to also back up your data, because data is the most valuable thing you have!