Cross-Site Request Forgery – All You Need to Know          

Introduction to Cross-Site Request Forgery (CSRF)

The Cross-Site Request Forgery (CSRF) vulnerability category spent over 10 years in the OWASP Top 10 (until the 2017 release), yet a large percentage of the development community still doesn’t understand the risk. Our team conducts hundreds of security assessments per year, and the results still show a high percentage of applications that do not have CSRF protection.

Before we define CSRF, let’s address the first question our customers ask. If CSRF is no longer in the OWASP Top 10, do I need to worry about it? Basic threat modeling can help answer the question. Start with this question: Do any of my web applications use cookie-based authentication? If the answer is no, then see your way out here. Unfortunately for most of us, our legacy and model-view-controller (MVC) applications use cookie-based authentication. If you fall into this group, then you have to address CSRF. The main reason CSRF was removed from the OWASP Top 10 is because modern frameworks, such as Spring Boot, .NET MVC / Core, and NodeJS, provide built in protection to prevent CSRF attacks. But, do you know if the CSRF feature is actually enabled and properly configured for all endpoints? Most security teams do not know the answer to this question, which is why you still need to worry about CSRF. Misconfiguration errors in these frameworks now lead to most of the CSRF vulnerabilities identified in our assessments.

 

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is an attack that abuses browser session management and tricks the browser into performing an attacker-controlled action. Let’s break this down and show you how this works, but to do so, let’s first make sure you understand session management in web applications.

Session management is really just a fancy way of saying the web application has memory. The HTTP protocol that web applications talk over is what we call a stateless protocol. It has no memory of previous requests you made to the web application or of the web application’s response to you. Not true, you say, you know for a fact that web applications have memory because you add things to Amazon’s shopping cart and the shopping cart does not automatically empty while you shop some more.  Yes, that’s because of session management. Many applications perform session management using cookies. Logging in to Amazon results in a cookie, which identifies your user account, being sent back to your browser. As you navigate with the Amazon website going forward, the browser sees that you are making a request to Amazon and sends the current cookie back to Amazon. This cookie tells Amazon the identity and account of the current user. Simply stated, the cookie provides Amazon memory of your interaction with their site and achieves session management.

How does this relate to CSRF? Before CSRF attacks were well documented, web applications assumed that incoming requests from your browser were intentionally sent by you. The web applications inherently trusted your browser. As it turns out, you cannot trust the user’s browser.

Suppose you want to do some online banking, so you go to your bank, MyBank.com. You log in and MyBank.com sets a cookie in your browser. When you go to deposit a check, you scan a picture of the check and you send that image to your bank to deposit the check. Your browser sees your request to MyBank.com sending the check image, and inserts your authentication cookie. Remember, this authentication cookie tells MyBank.com that the request came from your account.

Cross-Site Request Forgery Example

Consider the example above. Most users open one or more tabs in their browser window. If you open a new tab and browse to a new website, AttackerControlled.com, then you are opening yourself up to CSRF attacks. What you don’t know when you go to AttackerControlled.com is that AttackerControlled.com makes a request to MyBank.com to transfer $10,000 from your bank account to attacker’s bank account (also known as a cross-post). The request came from your browser, but it originated from AttackerControlled.com.

What does your browser do? The browser sees a request going to MyBank.com, inserts the current authentication cookie into the request, and sends it along to MyBank.com. MyBank.com receives the request, reads the authentication cookie, and performs the requested action. The attacker is happy to see $10,000 transferring from your bank account to the attacker’s bank account. But wait, you didn’t do that? You just were logged onto MyBank.com when you visited AttackerControlled.com. The evil site AttackerControlled sent a forged request. From the perspective of MyBank.com, you and your browser requested the action.

Cross-Site Forgery Request and the OWASP Top 10

As mentioned earlier, CSRF vulnerabilities were very widespread 10 years ago. OWASP first ranked CSRF #5 in the 2007 Top 10 list. In 2010, CSRF remained in the #5 position. In 2013, CSRF moved down to the #8 position before dropping from the list in the 2017 list.



Here’s why:

  • Modern Single Page Applications (SPA) may not store authentication data in cookies to manage user sessions. Instead, authentication data may be stored in the browser’s session storage database. This eliminates the CSRF because the browser will not attach the user’s authentication token to forged requests.
  • Secure frameworks (e.g., Spring Boot, .NET, and NodeJS) may have built-in protection for CSRF. Documentation for these features can be found in their documentation:

Based on the above, the problem was deemed “solved” and removed from the list to leave room for vulnerabilities that need more attention from the community. Does this mean you won’t need to worry about it? Absolutely not. If you are relying on secure framework configurations, security teams must review and scan for CSRF misconfiguration mistakes.

Well-known CSRF Attacks

There have been several major security breaches that occurred due to the exploitation of CSRF vulnerabilities. One example includes an attack that took place in Brazil against TP-link modems. In this example, the modem’s admin screen allowed attackers to change the DNS server address of a victim’s TP-link router. Attackers then controlled all DNS queries sent to the router. Victims were sent to  malware distribution sites and vulnerable to man-in-the-middle attacks. Other documented CSRF vulnerabilities in the wild include GoDaddy and PayPal.

Protecting a Site from Cross-Site Request Forgery Attacks

The most common CSRF defense uses synchronization tokens, also known as anti-CSRF tokens, to make requests unique. Synchronization tokens contain a large random string that is placed in a hidden field in a web form. Requests will contain the large random string, and the server (MyBank.com) is able to verify  the token value before processing the request. Attackers will not know the random token for the victim, which allows the server to identify forged requests and refuse the requested action.

Alternatively, some applications do not use cookies for authentication. Storing authentication tokens, such as JSON Web Tokens (JWT), in the HTML5 session store prevents the browser from accidentally sending the token during a forged request. This configuration is not vulnerable to CSRF, but does elevate the risk of other attacks like Cross-Site Scripting.

Using a CSRF Token

CSRF tokens can be unique (large random string) for page (or form), one value for the entire session, or somewhere in between (shared token for some forms, unique for others). CSRF tokens must be placed in a  hidden form field. It is important to realize that CSRF tokens CANNOT be stored solely in a cookie. If tokens are placed into a cookie, the authentication cookies and token will automatically be sent by the browser and the protection is defeated. Some implementations, such as the CSRF protection provided in .NET MVC, do place the token in a cookie and in a hidden form field. This allows the server to compare the two values on the server-side and avoid tracking tokens in session variables.

Tokens must be protected from the attacker to be effective. For example, applications vulnerable to Cross-Site Scripting can allow attackers to steal CSRF tokens and submit a valid forged request.

Summary

Despite being removed from the 2017 OWASP Top 10, CSRF still requires the attention of application and security teams. There are simply too many legacy applications and misconfigured framework options to ignore the issue. At the time of this writing, our security assessments still identify CSRF vulnerabilities in over  50% of web applications. If your team needs help understanding and reviewing your applications for CSRF, contact us to find out more about our application security assessments.

References:

“CSRF Attacks”

Retrieved from: https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html

“Prevent Cross-Site Request Forgery attacks in ASP.NET Core

Retrieved from: https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery

“Expressjs /csurf”

Retrieved from: https://github.com/expressjs/csurf

“Attack hijacks DNS settings on home routers in Brazil”

Retrieved from: https://www.pcworld.com/article/2602040/attack-hijacks-dns-settings-on-home-routers-in-brazil.html

“CSRF Flaw Allowed Attackers to Hijack GoDaddy Domains”

Retrieved from: https://www.securityweek.com/csrf-flaw-allowed-attackers-hijack-godaddy-domains

“Paypal Fixes CSRF Vulnerability in Paypal.me”

Retrieved from: https://threatpost.com/paypal-fixes-csrf-vulnerability-in-paypal-me/119435/

 

About The Author

Cypress Data Defense

No Comments

Leave a Reply