CSRF, short for Cross-Site Request Forgery, is one of the most common web attacks, along with XSS and SQL Injection. In simple terms, CSRF attacks trick users into performing unintended actions on a website. These attacks can lead to unauthorized activity, data loss, and other security breaches, making it a topic worth studying and understanding thoroughly.
CSRF Using HTTP GET Requests:
Let’s begin by exploring the simplest form of CSRF. Imagine you have a database of cars, and a GET request to /api/delete?id=1 will delete the car with ID 1. Now, suppose you visit another website that includes an image with the source URL: https://yoursite.com/api/delete?id=1. When your browser fetches this image, the request is executed, and the associated car is deleted. If the website requires authentication and you haven’t logged out, the request will be considered valid as your session is still active. This happens because any request to a domain automatically includes session cookies unless strict SameSite cookies are in use, fooling the server into thinking that the request is legitimate. To avoid such vulnerabilities, it is recommended to avoid using GET requests for data manipulation and instead use POST requests.
CSRF with Forms: To protect your application from CSRF attacks, you should ensure that every form in your app is equipped with a CSRF protection token. One popular middleware for enabling CSRF protection in Express is csurf. The idea is to embed a CSRF token in the form and validate it when you receive form data. For single-page applications (SPAs), you can create an endpoint to retrieve this token and store it in a cookie.
Solving CSRF Using SameSite Cookies: The SameSite attribute, unfortunately not supported by all browsers, allows servers to prevent cookies from being sent on cross-site requests (like image source links or iframe requests) but only allows them on resources with the same domain as the cookie’s origin. This attribute significantly reduces the risk of CSRF attacks. Modern browsers automatically set cookies to SameSite=Lax, which provides a balance between security and functionality. However, the most stringent level, SameSite=Strict, completely blocks session cookies from being recognized when users follow a link to a website. This level of protection is commonly employed by banks and other high-security applications.
Solving CSRF Using One-Time Tokens or Passwords: In an effort to prevent CSRF attacks, many organizations, particularly banks, use one-time tokens for even the simplest operations. This additional layer of security ensures that tasks like sending money require additional user verification, such as looking at a one-time token on a mobile app or entering a password. This approach significantly reduces the risk of CSRF attacks and strengthens overall system security.
By implementing the right countermeasures, we can protect our applications, just like banks and other critical services do. Taking inspiration from their practices can help us create a robust defense against CSRF attacks.