What is CSRF (Cross Site Request Forgery)?
联系我们CSRF Definition and Meaning
Cross site request forgery (CSRF or XSRF) refers to an attack that makes the end-user perform unwanted actions within a web application that has already granted them authentication. This makes a CSRF attack different from a cross-site scripting (XSS) attack because although an XSS—and a reflected XSS—attack also changes information on the target site, it does not require authentication.
How Does CSRF Work?
A CSRF attack hinges on the use of social 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 a Uniform 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.
How Does CSRF Work?
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.
How Do Hackers Construct a CSRF Attack?
There are several ways hackers fool end-users into submitting or loading information into a web application. A successful attack follows two basic steps:
- The hacker writes a script or designs an exploit URL.
- 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.
Using a GET Scenario To Execute a CSRF
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:
- 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.”
- 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:
- Sending an email containing the necessary HTML content
- 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.
Using a POST Scenario
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:
- Write the POST request that looks something like this: POST http://bank.com/transfer.do HTTP/1.1
- 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...`
Other HTTP Methods Attackers May Attempt
It is also possible to use DELETE or PUT commands. These can be executed by embedding JavaScript inside the exploit page. However, with the most recent versions of web browsers, this would be unsuccessful because of the same-origin policy, which dictates that a browser can only allow scripts on the first page to gain access to data on the second page if both of the pages come from the same origin.
Common CSRF Vulnerabilities
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.
The Validation Depends on the Request Method
In some applications, the validation is not performed correctly if the GET method is used instead of the POST method. All the attacker has to do is make a switch from using the POST method to using the GET method. This way, the attacker can bypass the validation process.
The Token Has To Be Present for the Validation To Happen
In some applications, the validation process is skipped when the token is not present. If the attacker is attempting to exploit this kind of web application, he just has to take out the code that has the token information. Then, with these kinds of applications, the process will be skipped altogether.
The Application Does Not Require the CSRF Token To Be Tied to the User's Session
There are applications that maintain a pool of tokens, and as long as the token presented is in that pool, it will be accepted. However, this means the token does not have to be linked to the user session. The attack just has to know which tokens are in the pool—or at least a single token that is in there—and the attacker can use that to gain access.
The CSRF Token Is Associated with a Cookie from a Different Session
A framework is a tool used by programmers as they develop software. With some applications, if there are two frameworks used, the cookies from both frameworks may be accepted. If this is the case, the attacker will have to put a cookie in the target victim’s browser. Then the attacker will log in with their own account and get a valid token and the cookie associated with it. Next, the attacker will place their cookie in the victim's browser. Because the validation accepts cookies from both frameworks, the attacker's cookie works as well for validation as the victim's cookie. All the attacker has to do is provide their token to the victim during the CSRF attack, and the validation is completed.
The CSRF Token is Duplicated in a Cookie
In some applications, there is no record kept of already used tokens. Instead, they duplicate each token in a cookie and the associated request parameter. This method works if the target website has the ability to set cookies. They can make up their own token using the format that the site is looking for, place the cookie they made into the browser the victim is using, and then provide their token to the victim as they execute the CSRF attack.
How To Prevent CSRF Attacks?
As long as an attacker knows the value combinations and parameters of the form a victim will fill out, they can launch a CSRF attack. So by including an additional parameter that has a value the attacker does not know, you can avoid CSRF attacks. There are a few ways to do this.
Use an Anti-CSRF Token
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.
Use the SameSite Flag Within Cookies
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.
How Fortinet Can Help
You can protect your web applications from CSRF attacks by either screening requests or accounting for vulnerabilities. Fortinet provides you with tools for both solutions. The FortiGate intrusion prevention system (IPS) protects you from CSRF attacks because it contains specific signatures designed to block them. If an attacker tries to execute a CSRF attack, the FortiGate IPS will recognize the attempt and prevent it.
Another CSRF protection tool is the Fortinet web application firewall (WAF). The Fortinet WAF recognizes CSRF and other OWASP Top 10 attacks. The WAF filters out untrusted information being submitted to your web application. In this way, it can block CSRF attacks, preventing the hacker from manipulating or changing user account information.
FAQs
What is CSRF used for?
Cross site request forgery (CSRF or XSRF) refers to an attack that makes the end-user perform unwanted actions within a web application that has already granted them authentication.
Why do CSRF attacks happen?
Cross site request forgery (CSRF or XSRF) refers to an attack that makes the end-user perform unwanted actions within a web application that has already granted them authentication.
What is a CSRF token?
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.
