Understanding CSRF (Cross-Site Request Forgery): A Comprehensive Overview

By using cross-site request forgery (CSRF), an attacker can force a victim’s browser to send a request to a website where the victim has already authenticated (such as a bank site). Without requiring the victim’s login credentials, the attacker can initiate actions such as money transfers if the victim clicks on a harmful link.

The Procedure for a CSRF Attack:

Victim Login and Establishing a Session:

A session is established when the victim logs into a website, such as a banking website. A Session ID, usually stored in a cookie on the victim’s browser, is used to identify this session. During this session, the victim can access their account and remain logged in without having to enter their credentials again for every action (such as transferring money).

Attacker’s Goal:

Now, the attacker’s goal is to transfer funds from the victim’s bank account without the victim’s direct interaction. This is carried out without being aware of the victim’s login information, including their username, password, PIN, etc.

Creating a Malicious Request:

It is not necessary for the attacker to log in. Rather, they produce a malicious URL that causes the victim’s bank account to be credited. Tricking the victim into clicking on this link is the attacker’s aim.

In order to get the victim to click on the link, the attacker uses social engineering to send it to them via email, social media, or another channel.

How the Attack Works:

The victim’s browser sends the request, along with the session cookie created when they logged in, to the bank’s server when they click on the malicious link.

The request is handled by the server as though it were from the authenticated user because it trusts the session cookie.

Since the victim is already logged in, the server assumes it’s a legitimate request and transfers the funds from the victim’s account to the attacker’s account.

Preventing CSRF Attacks:

Token-Based Security (Anti-CSRF Token):

Many frameworks, including Django, use this robust defense. The concept is that a distinct, random CSRF token is included in every form or sensitive action (such as money transfers).

When a user requests a sensitive action or loads a form for the first time, the server creates this token. With every request, this token is returned as a URL parameter, HTTP header, or form field.

With every request, the server verifies this token. The request is deemed invalid and blocked if the token does not match the expected one.

The attacker has no access to the valid CSRF token. Since they cannot predict or generate the correct token, their malicious requests will be rejected by the server.

Referrer Header Verification:

The server is informed of the origin of the request by the Referrer Header. The server can determine whether the request is coming from a reliable source or an external (malicious) website by looking at the referrer.

For instance, a request may be blocked if it originates from a suspicious source, such as the attacker’s website.