CSRF (Cross-Site Request Forgery) vs XSS

Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) is an attack targeting vulnerabilities in computer security, posing significant risks to user information and accounts. It manipulates the web browser to perform unwanted actions within an application, harming the user logged into the system. A successful attack can lead to unauthorized money transfers, data theft, password changes, and damage to customer relations.

Cross-Site Scripting

Cross-site scripting (XSS) is a Web security vulnerability that allows an attacker to compromise user interactions with an application by exploiting separate web sites. To avoid detection by the attacker, one should not rely solely on the same-origin policy.

Work Algorithm of CSRF

The CSRF (Cross-Site Request Forgery) attack exploits the trust that a web application has in a user’s browser. The aim is to deceive the browser into executing unwanted actions on a website where the user is currently authenticated. This section will break down how CSRF attacks are typically carried out in a step-by-step algorithm.

Step 1: Identifying the Target Application

The attacker first identifies a target web application that is vulnerable to CSRF. This typically involves an application that handles user requests without sufficient validation of their origin or authenticity.

Step 2: Crafting the Malicious Request

Once a vulnerable target is identified, the attacker crafts a malicious request that can perform an unwanted action on the application. This could be anything from changing user settings, transferring funds, posting data, or any action that the user is authorized to perform on the application. The request is designed to look like a legitimate request from the authenticated user.

Step 3: Delivering the Malicious Request

The crafted request is embedded in a place where the victim is likely to trigger it. Common methods include:

• Embedding the request in an image or script on a web page that the user is likely to visit.
• Sending the malicious link via email or social media where the user might click on it unknowingly.

Step 4: Executing the Request

When the user interacts with the malicious content (e.g., by visiting a malicious website, clicking on a deceptive link, or loading a compromised image), the malicious request is sent to the target application. Since the browser automatically includes credentials like session cookies with every request to the site, the application might process the request as legitimate.

Step 5: Action Performed

If the attack is successful, the application performs the action without the user’s conscious approval. The action is executed under the guise of the user’s authenticated session, leading to potentially damaging outcomes depending on what the malicious request was designed to do.

Step 6: Attack Detection and Response

Detection of CSRF attacks can be challenging as they originate from the trusted user’s authenticated environment. However, preventive measures such as implementing CSRF tokens, same-site cookies, or double submit cookies can effectively mitigate such attacks.

Cross-Site Request Forgery (CSRF)

CSRF attacks often rely on social engineering to succeed. The app cannot differentiate between legitimate requests and fraudulent ones since the user remains authenticated during the attack. For the attack to succeed, the attacker leverages three main keys, which we detail below:

• Relevant action: Any action that involves user data.
• Cookie-based session handling: This key involves sending one or more HTTP requests where the application identifies the user solely through cookies.
• No unpredictable request parameters: To prevent an attacker from discovering or guessing the value of a query, the query includes no parameters.

CSRF Example

Imagine a popular online forum where users can update their profile information, including their bio. The form to update the bio might look like this in normal use:

POST /updateProfile HTTP/1.1
Host: community-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Cookie: session=3e5e4f3a8
bio=I+love+networking+and+cybersecurity!


This action is vulnerable to CSRF for several reasons:

• The action of updating a bio doesn’t require any secondary validation, making it a prime target for attackers looking to alter user data subtly.
• The application relies solely on session cookies to authenticate requests, with no CSRF tokens or other anti-CSRF mechanisms in place.
• Form data for this action is simple and predictable, allowing an attacker to easily forge a request.

An attacker could exploit this vulnerability by crafting a malicious webpage that includes an auto-submitting form, as follows:

<form action="https://community-sample-website.com/updateProfile" method="POST">
<input type="hidden" name="bio" value="Hacked by evil-user!" />
<input type="submit" value="Update" />
</form>
<script>
document.forms[0].submit();
</script>


Here’s what happens when a victim, who is logged into the forum, visits this malicious webpage:

1. The hidden form on the attacker’s page automatically submits a POST request to the forum’s server.
2. Since the victim is logged in, their browser includes their session cookie automatically with the request.
3. The forum processes the request as if it were a legitimate action initiated by the victim, thus changing the victim’s bio to “Hacked by evil-user!” without their consent.

This example highlights the importance of employing CSRF tokens or other verification methods that verify the user’s intent on sensitive actions within web applications. Without these protective measures, users are at risk of having their data altered or hijacked by attackers.

Cross-site scripting (XSS)

To execute this attack, the attacker proceeds in two stages:

• The attacker first looks for a way to insert malicious code into the web page that the user visits, before launching the malicious code into the victim’s browser.
• If the attacker targets a specific victim with malicious code, he does it through phishing or social engineering. Once he embeds the malicious code in the web browser, the victim must visit this infected website.

What is the Difference Between XSS and CSRF?

Now that we understand what XSS and CSRF entail and how they operate, let’s explore the differences between them:

Can CSRF tokens prevent XSS attacks?

Effective CSRF tokens can prevent XSS attacks. Assuming the server still validates the CSRF token correctly, the token can block an XSS vulnerability. Considering the term “intersite scripting”, we notice a hint that the intersite query can appear in reflected form. The application blocks the trivial use of an XSS vulnerability, thereby preventing an attacker from faking an intersite request. However, there are important caveats:

1. There may still be an exposed, tokenless XSS vulnerability within a function that can be exploited in the usual way.
2. Actions protected by a CSRF token can still be executed by the user, but if there is an XSS vulnerability elsewhere, it could be exploited. In such cases, an attacker’s script may request the corresponding page to obtain a valid token, which he can then use to perform any protected action.
3. If XSS vulnerabilities are already present, CSRF tokens cannot protect them. You can only use pages that are output points for the stored XSS vulnerability, protected by the CSRF token. When the user visits the page, the XSS payload will execute.