What is CSRF (Cross Site Request Forgery)? | Fortinet (2024)

A CSRF attack hinges on the use ofsocial engineering. An attacker fools their victim by sending a link through a chat or email.When a victim is a user without admin privileges, the CSRF attack can make them do things like change an email address as it appears in the target site’s system, transfer funds from an account, change username information, and more. If the victim has administrator privileges, the CSRF attack can be used to alter the function of the web application itself.

CSRF attacks focus on functions that change the server of a target web application. How an attacker exploits the changes enacted by the attack varies depending on their objectives. They may want to steal money right then and there. Or they may want to wait until a later date to alter the information on the server. The attacker may also change the account information and then sell the credentials to a buyer.

At times, the CSRF attack script can be stored on the target site. In Hypertext Markup Language (HTML) coding, an IMG file is used to store images, and an iframe tag is used to put a document within the page. If an attacker is able to gain access to the site's HTML code, they can embed the CSRF attack code within an IMG file or iframe tag. These types of vulnerabilities are known as stored CSRF flaws. This type of attack can also be accomplished through more complicated XSS methods.

The issues a CSRF attack causes for the target are worse if the CSRF can be stored on the actual site. If the victim gets directed to another, seemingly random page in the midst of the attack, they are more likely to suspect something is wrong. However, if the page they get directed to belongs to the site they are visiting, it looks less suspicious. They may assume the redirection is happening because while the page they were on initiates the transaction, the page they are being redirected to simply performs the next step.

When you are making a purchase on Amazon, for example, after you click to buy the item, you get redirected to another page, but that page is still part of Amazon's site. On the other hand, if you are redirected to a different site with aUniform Resource Locator (URL)other than Amazon.com, you may think twice about the validity of the transaction. Embedding the CSRF attack within the target page itself may alleviate potential suspicion on the part of the victim.

As you browse a website, the site can request data from another site for you. A common example is a video embedded on a webpage. In many cases, the video is not hosted on the page’s server. Instead, it is on YouTube or another video site like Vimeo. To make content and script files available without expending extra resources, sites often use content delivery networks (CDNs) to store elements they want to make available to their users.

In the end, this practice makes for a smoother browsing experience. However, it also presents a serious security vulnerability, particularly if the website requests that the user's browser obtain data from a different website without the user's consent. If these requests are not dealt with properly, the attacker can execute a CSRF. This cyber threat is serious enough to have made the Open Web Application Security Project (OWASP) Top 10 list multiple times.

There are several ways hackers fool end-users into submitting or loading information into a web application. A successful attack follows two basic steps:

1. The hacker writes a script or designs an exploit URL.
2. The attacker fools the target into executing the desired action.

For example, let us say Mary wants to send money to Darren, but an attacker named Joe wants Mary to send the money to him instead. This can be accomplished using a GET scenario or a POST scenario.

Step 1: Creating the Exploit URL

If the web application was made to use GET requests to send parameters and perform actions, the transfer operation for sending a specific amount of money, say $50, to Darren’s account may look like this:

GET http://bank.com/transfer.do?acct=DARREN&amount=50 HTTP/1.1

The attacker, Joe, now exploits the web application that performs this action. He writes the exploit URL so two things happen:

1. A greater amount is requested, such as $50,000 instead of $50. This is done by changing what comes after “amount” from “50” to “50,000.”
2. The money goes to the attacker, Joe, instead of the intended recipient, Darren.

Therefore, the exploit URL can look something like this:

http://bank.com/transfer.do?acct=JOE&amount=50000

The next step is to get the target, Mary, to execute the transaction.

Step 2: Using Social Engineering To Execute the Attack

The goal of the social engineering factor is to fool Mary into loading the URL while she is logged in to the bank’s web application. To do this, the attacker can use a few different methods, including:

1. Sending an email containing the necessary HTML content
2. Embedding the exploit URL (or an exploit script) in a page the victim may likely visit while performing online banking

For example, the exploit URL can be disguised as an innocent link asking for something else, such as “Check out my video!” This text could be put inside an innocent-looking link or a fake image. As long as Mary clicks on the link while logged in to the online banking application, the attack will be successful. The page Mary visits can be a website the attacker got her to visit at the time. The attacker could also have sent her an email with the attack script inside it. As soon as she clicks the page or the link in the email, the request is sent, and the money gets transferred to the hacker's account instead of Darren’s.

When an attacker uses a POST scenario, the method is nearly the same as with a GET scenario, except the victim is used to execute the attack. For example, the attacker can trick the victim into clicking inside a form, and as they click, they initiate the POST request. If this is the method used, the attacker will take the following steps:

1. Write the POST request that looks something like this: POST http://bank.com/transfer.do HTTP/1.1
2. Use a FORM tag to deliver it, which may look like this:

<form action="http://bank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="JOE"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="View my pictures"/>
</form>

Have the user click on a submit button using JavaScript that looks something like this:

<body onload="document.forms[0].submit()">

`<form...`

Some of the most common CSRF vulnerabilities come from mistakes made in the process of validating CSRF tokens. A CSRF token refers to a unique value generated by the application on the server’s side. The validation process involves a few steps. After the token is created, it is then sent to the client so it can be included within an HTTP request the client makes later. Once the request is made, the server-side application checks it to see if it includes the token it expects to see.

Ideally, this process would work well. However, there are a few ways it can be broken.

An anti-CSRF token is used in server-side CSRF defense. It consists of a random string that only the user’s browser and the web application know.

If the session variable’s values match the hidden form field, the application will accept the request. If the two values do not match, the request gets dropped. The attacker does not know the value within the hidden form field, so he cannot use it to get the request accepted. This stops the CSRF attack.

If the session cookie is designated as a SameSite cookie, it can only be sent with requests that come from the same domain. The attacker’s domain, in most cases, will be different from that of the target website. Therefore, the session cookie that gets generated will not be from the same site. If the SameSite cookie is used, attempts by an attacker to send POST requests will be blocked because they come from a different domain.

However, if a hacker somehow gains access to the target domain and works from within it, it is possible that the request will come from the same site and pass the SameSite “test.” It is therefore crucial to have adequate protection for any web applications and the servers that host them. Otherwise, an attacker can launch attacks that will satisfy the SameSite protocol and exploit the accounts of your users. In addition, a page within your domain has a higher chance of looking legitimate, even if it is more basic than other pages. This could help an attacker gain the trust of your unsuspecting customers.