What Is CSRF?｜ExplainThis

In "What Is XSS?", we discussed what is XSS and how to defend it. In this article, we will continue to discuss another common network attack method - Cross Site Request Forgery (CSRF).

What is CSRF?

CSRF refers to cross-site request forgery. This way of attack will force users to execute unwanted malicious forgery requests on websites the user has authenticated. Because the user has been authenticated, the website has no ways to distinguish forged requests and actual requests. So the request will be accepted. For example, after a user logs into his bank account, he accidentally visit a malicious website. The code in the malicious website can use the user's credentials to make an unauthorized money transfer request.

CSRF works because the user's identity has already been verified first. To understand it in plain language, it's like someone stealing your membership card and use it to buy stuffs. Since the store recognizes the card, when the store staff sees the thief holding your card, he believe that the thief is you, so the store accepts the thief's to use your points for consumption.

CSRF attack process

The user successfully logs in to the account of Bank A website, and the cookie representing the user’s identity is saved locally, so next time the user comes to the website of Bank A, there is no need to log in again.
The user has not logged out of the account of Bank A website, when browsing the malicious website B, there is a image set to be transparent on the website B, since it is transparent, the user cannot see it on the screen. The image contains a piece of malicious code, the code is as follows.

// Remarks: There are many CSRF attack methods, this code example is one of the most basic attack methods
<img
  src="http://a-bank.com/transfer.do?acct=BadGuy&amount=100000 HTTP/1.1"
  width="0"
  height="0"
/>

Although the user will not be able to see the image, due to the malicious code, the browser will still submit a request to http://a-bank.com/. This request contains the user's cookie, so Bank A identifies it a a request from the user. Hence, this malicious attack was successfully executed.

How to defend CSRF attacks?

Don't use `GET` requests for critical operations

The above example of passing the request to the image is a very common way of attack. This attack is easy to do because of the use of GET requests for operations. Therefore, if you want to avoid CSRF, the most fundamental approach is not to use GET requests for key operations. It is often recommended to use POST requests.

Of course, this does not mean that it is absolutely safe to use POST request, but if you use POST request, it will need to be triggered by the user's submit action. Many phishing websites will entice users to click certain buttons, precisely because the submission action of clicking is required to trigger CSRF attacks. Although it is still possible to be attacked, at least it is not like using a GET request. Users may be attacked immediately after entering the website without knowing it when using GET.

Check Referrer

To be able to avoid cross-site forgery requests, one way is to first identify which website the request is from. Even if there is a mechanism for authenticating users such as cookies, if it can be identified that it is not from the original website, forged requests can be filtered out. There is a Referrer field in the HTTP header, we can check this field to ensure that the request does not come from other websites.

However, this approach is having a flaw. Since this Referrer field is provided by the browser, in other words, the security of your website will depend on the browser. If the browser has some security vulnerability, a hacker might be able to modify the value of Referrer, meaning it is still possible to be successfully attacked.

CSRF token

The cookie used for identity authentication is automatically included in the request by the browser every time a request is sent, which allows malicious websites to get the cookie, so it can be used to make forged requests. To avoid forge requests, we can use CSRF tokens. CSRF token is a way that allows a website to verify the identity of the user in a different way other than cookies.

The CSRF token needs to be generated from the server side. It can be generated once for each request or each session, but it is more secure to generate for each request. Then, this token will be sent to the client. The client can store it in a hidden field in the form.

When the client sends a request, it will submit the token back to the server together, or send it back to the server as part of the header. The server will reject the request if the token provided by the client is different from the one in the server.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="123token123">
[...]
</form>

SameSite cookies

Since many CSRF attacks are due to cookies being used by malicious websites to forge requests. If you want to avoid this, you can actually restrict cookies to be used only by your own website. How to restrict cookies to only be used by your own website? We can do it through SameSite cookies.

SameSite cookies are one of the attributes of Set-Cookie in the HTTP response header. You can set this attribute to be Lax, Strict or None. Lax or Strict values can prevent third-party websites from carrying cookies so they can help us defend against CSRF attacks. The safest way is using Strict, which can prevent the browser from bringing cookies in all cross-site requests, so that cookies can only be used in your own website. With this, you don’t have to worry about forged requests.

Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict
Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

The above is an introduction to CSRF, how to attack it, and how to defend it. In front-end interviews, this is a very common question. You must read it well to make sure you can answer well in the interview!