Are Your Customers Protected From CSRF?

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 they target 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.

Let's explore CSRF to help plan your cybersecurity roadmap:

What is Cross-Site Request Forgery?

In short, a cross-site request forgery is an attack that 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?

Without proper safeguards, Cross-Site Request Forgery (CSRF) can expose end users to serious compromise, directly impacting the confidentiality and integrity of their data within trusted web applications. In many cases, CSRF attacks exploit the way an application manages authenticated user sessions. This allows attackers to hijack active sessions and perform unauthorized actions on behalf of legitimate users.

For example, an attacker might trick a user into unintentionally changing their account password to one controlled by the attacker or modifying a shipping address to redirect orders without the user’s consent. Historically, even banking web applications were vulnerable to CSRF, enabling attackers to transfer funds to their own accounts without detection.

If unmitigated, a CSRF vulnerability can erode customer trust and lead to significant financial and reputational damage. For organizations handling sensitive data or financial transactions, these vulnerabilities can be devastating, compromising not only systems but also brand integrity and client confidence.

Addressing CSRF vulnerabilities is non-negotiable; they must be identified, remediated, and validated to maintain secure web applications and protect user trust.

The Technical Trenches of CSRF

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, please skip to the Remediation section.

Why Do CSRF Vulnerabilities Exist?

In order to explain why this class of vulnerabilities exists, it is necessary to understand a standard authentication flow. When a user 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, they are permitted 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 prerequisites 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 prerequisites for a modern CSRF attack are met.

Prerequisites For a Traditional CSRF Attack

A traditional CSRF attack 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

Prerequisites 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.”

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.

CSRF Attack Flow

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

• The 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.

Following such an attack, an attacker would effectively possess 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 With CSRF Vulnerabilities

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.