Cross-Site Request Forgery Guide: Learn All About CSRF Attacks and CSRF Protection

What is Cross-Site Request Forgery (CSRF)?

Cross-site request forgery, also called CSRF, is a type of web security vulnerability identified as one of the OWASP Top 10 Web Application Security Risks. A CSRF attack can be used to send unwanted requests to a web application or site from an authenticated user. This allows an attacker to craft malicious content to trick users who are already logged in and authenticated on a legitimate website to perform actions that they do not intend to and may remain unaware of.

Key Concepts of Cross-Site Request Forgery

Cross-site request forgery attacks are a type of credentials management flaw. The vulnerability to CSRF attacks lies in the web application the user is logged into.

• CSRF attacks are often targeted, relying on social engineering like a phishing email, a chat link, or a fake alert to cause users to load the illegitimate request, which is then passed on to the site where they are authenticated.
• CSRF attacks generally focus on state changes, such as changing the email address associated with an account, making a purchase, or transferring funds from online banking.
• For administrator-level users targeted with CSRF, this type of flaw can open vulnerabilities to a web application or site overall by adding new administrator accounts or changing administrator login information.

When a user is logged into a website, the browser sends some form of authentication data as session information with each request to that website, such as a session cookie, client certificate, or other stored credential. A CSRF flaw means that site does not distinguish between intentional actions taken by the user and forged requests generated by a malicious link or script request.

Rates of Credentials Management Flaws in Software

CSRF is one type of credentials management flaw. Some type of credentials management vulnerability exists in 42% of applications, according to Veracode static scan data.

While CSRF may be less common than, for example, the use of hard-coded passwords to operate certain types of devices, it is a form of insufficiently protected credentials. CSRF vulnerabilities may be especially concerning given how much people rely on web applications to manage important aspects of their daily lives and how much personal and business information is tied directly to web applications. CSRF attacks can also be used to exploit flaws in internet-connected devices from home routers to Internet of Things (IoT) devices—the same systems often vulnerable to other types of credentials management problems, such as hard-coded or default passwords.

This flaw is especially concerning to businesses and others with some type of administrator-level access to web applications. For example, people with access to the back end of a company's website may inadvertently send requests from an attacker. CSRF vulnerabilities can allow an attacker to gain administrator-level access or take over the site when a plug-in or module code that contains these flaws is active on the site.

How Cross-Site Request Forgery Attacks Work

CSRF attacks exploit flaws in the ways web applications handle authentication and credential checks. CSRF attacks require that the user is authenticated against the targeted site with some form of persistent cookie or credentials. This means that every request sent by their web browser to the targeted site will include those cookies or credentials. This is an important part of the functionality of most sites that require a user to log in. After all, people would quickly leave a social media or membership site that forced them to log in again every time they visit another page or open a new browser tab.

When CSRF requests are sent by someone who is not logged in, nothing happens; the request is simply discarded by the target site. When CSRF flaws are found in a site or application, these same requests from a logged-in user's browser can execute an array of state change requests.

Protecting a web application against CSRF flaws allows the application or target site to differentiate such unwanted requests from legitimate requests, and this protection can be achieved without detriment to the user experience.

In many cases, CSRF attacks originate from unwanted emails or questionable websites, so teaching users not to click phishing links can play some role in protection. However, the most powerful form of protection against this type of attack is to ensure that the request comes from a form that the user previously requested in the session to verify the information before submitting it.

Executing a CSRF Attack

In a Cross-Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited, the victim must be authenticated against (logged into) the target site. For instance, let’s say examplebank.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on examplebank.com but am not currently logged in, nothing happens. If I am logged in, however, the requests in the attack will be executed as if they were actions that I had intended to take.

Let’s look at how the attack described above would work in a bit more detail. First, let’s assume that I’m logged into my account on examplebank.com, which allows for standard online banking features, including transferring funds to another account.

Now let’s say I happen to visit somemalicioussite.com. It just so happens that this site is trying to attack people who bank with examplebank.com and has set up a CSRF attack on its site. The attack will transfer $1,500.00 to account number 123456789. Somewhere on somemalicioussite.com, attackers have added this line of code:

<iframe src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789" >

Upon loading that iframe, my browser will send that request to examplebank.com, which my browser has already logged in as me. The request will be processed and send $1,500.00 to account 123456789.

Another Cross Site Request Forgery Example

I just bought a new home wireless router. Like most wifi routers, it’s configured through a web interface. The router was shipped to me with an internal IP address of 192.168.1.1. I’m having trouble configuring the router though, and fortunately the folks over at somemalicioussite.com have published a guide that shows me exactly what buttons to click in the router interface to get everything set up securely. The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.

As I clicked through the configuration guide, I missed the 1x1 pixel image that failed to load:

<img src="http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89" alt="pwned" height="1" width="1"/>

The attackers knew that when I was reading their tutorial, I would be logged into the router interface. So they had the CSRF attack set up in the tutorial. With that request, my router would be reconfigured so that my traffic will be routed to their proxy server where they can do all manner of bad things with it.

Preventing Cross-Site Request Forgery Vulnerabilities

Organizations can easily prevent most CSRF attacks by the use of a CSRF token. These unique tokens can be appended to each sensitive request. By adding a challenge token to every state change request, from transferring funds to creating administrator accounts on a website back end, and properly checking that token when processing requests, developers can ensure that these requests are legitimately submitted by authenticated users.

Each time the server renders a page that includes sensitive actions, a unique CSRF token is passed to the user. For this system to work properly, the server must then only take the requested sensitive action when the token is fully validated, rejecting all requests with either invalid or missing tokens. One common error when implementing CSRF flaw checks is to reject requests that have invalid tokens but allow requests with missing tokens to proceed, rendering the token process ineffective.

Finding and Remediating Cross-Site Request Forgery Vulnerabilities

To check for CSRF vulnerabilities, look for forms that allow users to make requests and check to see if an anti-CSRF token is generated properly. Most modern web frameworks can be configured globally to include anti-CSRF tokens on all form pages and to handle the verification transparently. Any time a user can submit a state-change request, such as transferring funds, making a purchase, adding an administrative user, or changing a password, this request must be protected by a CSRF token. If a form is not intended to allow users to make this type of change, its scope should be constrained to prevent misuse by attackers.

CSRF tokens can also be combined with other types of protective coding, including ensuring that session cookies are set with the SameSite cookie attribute. This attribute allows developers to instruct browsers to manage whether cookies are sent along with requests from third-party domains. Online banking sites, for example, may want to use the strictest level of cookie protection. You can also add the HttpOnly attribute to protect against some forms of cross-site scripting flaws; doing so also makes CSRF attacks more difficult to execute, as cross-site scripting vulnerabilities enable some types of CSRF attacks.

Veracode Can Help Defend Against Cross-Site Request Forgery Flaws

Veracode's web application scanning combines static analysis and dynamic analysis with web application perimeter monitoring to discover and protect external web applications. This dynamic analysis can find CSRF flaws in web applications, including those in both production and pre-production environments, allowing developers to find, target, and remediate vulnerabilities.

Veracode static analysis can find CSRF flaws and other credential management vulnerabilities in web applications, including third-party components and plug-ins, pointing developers to how and where repairs can be made, even without examining the source code.

With Veracode's cloud-based application analysis and developer enablement products, your developers can get the tools and training they need to manage application security, avoid and repair CSRF vulnerabilities, and address other flaws, all with integrated eLearning materials to expand developer skills and fix flaws earlier in the development process.