Blog

Cross-site request forgery (CSRF/XSRF) has become a term that is often confused with cross-site scripting (XSS). These two vulnerabilities are in fact, two separate issues. CSRF vulnerabilities rarely make headlines for massive breaches because it targets an application’s users, but there are still some notable mentions. In 2010, Twitter made headlines when a CSRF vulnerability made tens of thousands of Twitter users post tweets unwillingly. Similarly, in 2013, eBay was vulnerable to account hijacking through CSRF. Without an adequate understanding of this vulnerability, your organization’s user base may be at risk of fraudulent requests made on their behalf or account takeovers.

What is Cross-Site Request Forgery?

In short, a cross-site request forgery is an attack which forces end users to execute unwanted actions on a web application that are currently logged in. If the victim has a valid session on the trusted application, and with parameters (such as bank account, password, address) that are known to the attacker in addition to chaining exploits or through social engineering or phishing, an attacker can entice users (via email or chat) and force them to execute actions of the attacker’s choosing. Essentially, this attack exploits a trust relationship that authenticated users have with a trusted application.

What is the impact of CSRF?

With no mitigating controls, cross-site request forgery can leave an application’s end users at a high risk of compromise resulting in an impact to the confidentiality, and integrity of their data on the trusted web application. In many cases, a CSRF attack abuses how the application handles their sessions. This translates to attackers being able to hijack a user’s session in order to perform actions that your customers did not intend. As an example, an adversary can trick a user into changing their account password to a password of the attacker’s choosing, or change the shipping address to an address the attacker controls without the user’s knowledge or permission. About a decade and a half ago, when banking web applications were in a more precarious situation than today’s time, a standard transaction flow may be susceptible to a CSRF attack. Attackers would transfer an arbitrary amount of funds to an account in the attacker’s possession. Without addressing this vulnerability, your organization may lose the trust of your customers. CSRF vulnerabilities should never be left open; they must be fixed in all circumstances. If your business centers around transferring funds or the account information are sensitive, a CSRF vulnerability that is exploited may cripple the reputation of your organization and the trust of your clients.

Technical Trenches

This section is geared towards application developers or system architect engineers who are seeking to understand why CSRF vulnerabilities exist, how they work, and different types of mitigations. For those not looking to get deep in technical details, you can skip to the Remediation section.

Why do CSRF Vulnerabilities Exist?

In order to explain why this class of vulnerabilities exist, it is necessary to understand a standard authentication flow. When a user that logs in to www.vulnerablesite.net the user would receive a SESSION_ID cookie. This cookie is used by the application to identify who the request is coming from, and that they are authenticated to the application. Since the HTTP protocol is stateless, session cookies are often used to identify and differentiate between different users. When browsers have session cookies saved for authentication and authorization for a target site, it will include them automatically include them in a cross-site fashion. For example, if a user logs into www.vulnerablesite.net, and then browses to www.attackercontrolled.com, the latter domain would not able to read cookies from the initial website. However, if there is a request on www.attackercontrolled.com that sends a request to www.vulnerablesite.net, any saved SESSION_ID for www.vulnerablesite.net would be sent along with it.

A successful CSRF exploitation of such behaviour requires an attacker to set up a malicious website under their control to send GET or POST requests to www.vulnerablesite.net. Ideally, this would be done without any additional user interaction other than visiting the attacker-controlled page. Given that www.vulnerablesite.net has a section where after users have logged in, allowed them to change their passwords, email address, or shipping address, merely navigating to the attacker-controlled page would effectively change any or all of these values. Please note that this attack can only be carried out if it meets the pre-requisites for a traditional CSRF attack.

With the introduction of modern web frameworks, CSRF vulnerabilities are harder to exploit. Sometimes, the requests that make changes to the user’s email address, password, and/or shipping address may be handled by a PUT, DELETE or a PATCH request. While these HTTP methods may not be sent via an HTML form, attackers can still make use of the XHR or fetch API to craft a CSRF attack especially if there is a CORS misconfiguration which will allow an attacker’s website to send these requests to the victim’s origin. Again, this assumes that the pre-requisites for a modern CSRF attack is met.

Pre-requisites for a Traditional CSRF Attack

A traditional CSRF attack is one that is usually carried out through an HTML form via a GET or a POST.

• The victim must have a valid session at www.vulnerablesite.net when they issue a request from the malicious page

• Session cookies are used for authentication and authorization

• Parameters in the CSRF requests not random and known to the attacker

Pre-requisites for a Modern CSRF Attack

A modern CSRF attack is not carried out through an HTML form and is usually done by utilizing PUT, DELETE, or PATCH methods.

• Content-type for the request is either text/plain, multipart/form-data, or application/x-www-form-urlencoded

• The vulnerable application must not set any custom request headers

• Ability to avoid a CORS preflight request

CSRF Attack Scenario

Let’s walk through a fictitious example of the same grocery store used in the SQL Attack Scenario.

The grocery web application allows users to log in to change their username settings, passwords, and shipping and billing addresses. To discover a CSRF vulnerability, an attacker would replace the process of updating a user’s information to observe whether or not session cookies are being used for authentication and authorization, whether or not the update account flow has any non-predictable parameters, check if there are any CSRF prevention mechanisms and evaluate their effectiveness. Some parameter values that don’t change in most applications include (these fields vary from application to application):

• Email Address

• Password Field

• Shipping Address

• Account Number

• Transfer Amount

Once this information is obtained, an attacker can host a page that mirrors the real site and craft a form that sends the exact request that the application does in a legitimate account update flow. The screenshot below shows an example where an account’s password change on www.vulnerablesite.net has a predictable parameter of “changepass” for a password change and the logged in user is associated with the “session_id.”

Valid Password Update Flow on Vulnerable Application

The narrative below describes a scenario where an attacker has identified a potential victim who has an account and is logged in on www.vulnerablesite.net.

High-Level Overview of CSRF Attack Infographic

Attack Flow

• Attacker through the use of another vulnerability, or social engineering and phishing entices them to visit their page hosted on https://www.attackercontrolled.com/account.

• Victim navigates to the malicious website under the control of an attacker.

• Once the page loads or if the victim is enticed to click on a button of a hidden form.

• A request is sent to www.vulnerablesite.net. One thing to note is that if the browser has a session_id cookie that handles authentication and authorization, it would include them in a cross-site manner.

Following such an attack, an attacker would effectively be in possession of the victim’s account.

How do I address CSRF vulnerabilities?

CSRF vulnerabilities have been around for quite some time, and only recently with the advent of web frameworks have begun to address this. However, many older technology stacks do not automatically address this; therefore, a need to implement protection against CSRF may be necessary. From a technical standpoint, several techniques have been vetted by security experts and developers alike:

• CSRF Tokens: This is essentially adding a random value that is hidden in the form field or adds a custom header to an API request every time a user submits a sensitive request (such as a password change for their account). One significant thing to note here is that the token must be uniquely associated with a user’s session; otherwise, attackers may be able to acquire a valid token

• Captcha: Not only does this prevent spamming, but it is an effective mitigation technique against CSRF as it requires an input that is random and unknown to the attacker

• Re-Authentication: On more sensitive requests such as a password change or money transfers, it would prompt the user to enter their password again which would be unknown to the attacker

• Double Submit Cookie: Sends a random value in both the cookie and request parameters. The server will verify if the cookie value and the request value to see if they match. Be duly noted that this mitigation only works if the entirety of the application accepts on HTTPS connections and have a proper handle on their subdomains.

How We Can Help

The Packetlabs team is composed of highly trained and experienced ethical hackers that focus and excel at the discovery, exploiting, and chaining together multiple vulnerabilities that often are overlooked. Our team members have some the highest regarded training in the offensive side of information security including the Offensive Security Certified Professional (OSCP), Offensive Security Certified Expert (OSCE), GIAC Web Application Penetration Tester (GWAPT), and GIAC Exploit Researcher and Advanced Penetration Tester (GXPN) certifications. Please do not hesitate to contact us to learn more or speak to us about how we can help.