top of page

CSRF vs. XSS



Trust is the foundation of any successful business. Unfortunately, it's also a tempting target for attackers. Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS) are two popular and sneaky tactics attackers use to exploit customers' trust by hijacking user sessions and stealing sensitive data.


The scale of the problem is staggering. In 2022, there were 5.5 billion malware attacks, and the projected cost of cybercrime is set to hit $10.5 trillion by 2025. That's not just the cost of fixing things – it also includes the steep price of losing customers' trust. Gaining a solid understanding of these attacks is crucial to shielding your digital assets from such threats.


What is CSRF and How Does it Work?


Cross-Site Request Forgery (CSRF) tricks users into unintentionally carrying out harmful actions on a web application where they're logged in. It works by exploiting web apps' trust in users' browsers.


Imagine a user logging into their bank account at www.mybank.com. The bank's web app trusts requests from the user's logged-in session. An attacker can exploit this trust by convincing the user to click a manipulated link, secretly triggering a request to transfer funds from the user's account.


Here's how it works:

The malicious request appears just like a regular transaction made by the user. Since the user is logged in, the bank app authorizes it without verifying whether the user wants to do the action. The cybercriminal can sneakily place the deceptive link on another website, in an email, or in a chat app. When the user clicks, the funds transfer happens in the background.


The 2 Main Types of CSRF Attacks

CSRF attacks generally fall into two categories based on how the malicious requests are generated. Both CSRF attack types exploit the implicit trust apps place in authenticated sessions. Understanding how they work is key for developers to implement robust protections like anti-CSRF tokens.


Login CSRF

In a login CSRF attack, the attacker fools the victim into logging in using the attacker's credentials instead of their own. For example, the attacker could create a fake login page and send the link to the victim. When the victim enters their username and password, it authenticates the attacker's account without the user realizing it.


Once logged in as the attacker, any actions the victim performs on the site will be attributed to the attacker. This activity could allow the attacker to post malicious content, access sensitive information, or manipulate the victim's account. Guarding against these threats requires more than just awareness training for brand impersonation attacks and traditional tools.


Stored CSRF

Stored CSRF attacks involve the attacker storing malicious scripts on a vulnerable website. When victims visit the site, the script automatically executes and forces their browser to craft forged requests to target web applications they are logged into.


For example, an attacker could upload a script that automatically changes the email address on a victim's social media profile when they visit the site. Since the victim is already authenticated, the social media site cannot know the request wasn't legitimate.




What is XSS and How Does it Work?


Cross-site scripting (XSS) attacks inject malicious scripts into legitimate web pages that users view. Unlike CSRF, which exploits trust in the user's browser, XSS takes advantage of users' trust in websites. The attack unfolds by manipulating vulnerable websites to deliver malicious JavaScript code the victim's browser executes.


For example, a website displays user comments without properly sanitizing the input. An attacker could submit the following comment:


<script>sendSensitiveDataToAttacker();</script>

If the website shows this comment as-is, the script tag will execute in the victim's browser when they view the page. When this happens, the attacker can steal sensitive data like session cookies or impersonate the victim – which can mislead even the most tech-savvy employees and is a critical attack vector.


Main Types of XSS Attacks

XSS attacks generally fall into one of three categories, and understanding them is essential for XSS prevention strategies:


Stored XSS

Stored XSS involves the attacker permanently storing malicious scripts on the target website's server, for example, by submitting a comment on a blog that contains a script. When victims load the compromised page, the script executes in their browser. This type of XSS can happen whenever websites display stored, unchecked user input. The victim only needs to view the page for the attack to succeed.


Reflected XSS

In a reflected XSS attack, the malicious script comes from the victim's request to the website. Attackers trick victims into clicking crafted links or submitting forms that contain scripts. The website reflects the input back in the response, causing the victim's browser to execute it.


// crafted link example


www.malicious-site.com?payload=<script>sendDataToAttacker()</script>


Reflected XSS relies on social engineering victims to initiate requests with the attack payload. Proper input validation on the server side can prevent reflected XSS.



Key Differences Between CSRF and XSS?

Although CSRF and XSS are common cyber attacks, they have some significant differences.


User Interaction

XSS attacks don't require any user interaction beyond visiting a compromised site. In contrast, CSRF attacks typically require the user to act by clicking a malicious link or accessing a crafted page. The user, often unknowingly, initiates the CSRF attack by interacting with the attacker's payload.


Session Requirement

XSS attacks don't require an active session with the targeted site; the attack can be successful regardless of the user's authentication status. On the other hand, CSRF attacks demand that the user has an active session with the targeted site. CSRF leverages the user's authenticated status to execute unauthorized actions.


Trust Exploitation

XSS attacks exploit a user's trust in a website by injecting malicious scripts that run within the user's browser on trusted sites. In contrast, CSRF attacks exploit a website's trust in a user's browser, allowing attackers to perform unauthorized actions on behalf of the authenticated user.


Scope of Actions

CSRF is restricted to a user's actions on a targeted site. In contrast, XSS can execute arbitrary scripts, expanding the scope of potential actions an attacker can perform within the user's browser.


Attack Initiation

CSRF attacks require the user to access a malicious page or click a link, initiating the attack through user interaction. In contrast, XSS attacks only require a vulnerability in the website, with the user becoming a victim simply by visiting a compromised page. A great free WAF solution should be able to help prevent both CSRF and XSS attacks before they happen.


Data Access

CSRF attacks can only send HTTP requests and cannot view the response, while XSS can send and receive HTTP requests and responses, enabling the attacker to extract required data.


Consequences

The consequences of XSS vulnerabilities are generally more serious than those of CSRF vulnerabilities. A successful XSS exploit can induce a user to perform any action, regardless of the vulnerability's functionality.


How WAF Can Protect Against CSRF, XSS, and OWASP Top 10?

XSS and CSRF are two of the most popular cyberattacks used to exploit the trust between users and online platforms. These deceptive actions hurt user privacy, cost companies a lot of money, and damage their reputation, making customers lose trust.

 

open-appsec is an open-source project that builds on machine learning to provide pre-emptive web app & API threat protection against OWASP-Top-10 and zero-day attacks. It simplifies maintenance as there is no threat signature upkeep and exception handling, like common in many WAF solutions.


To learn more about how open-appsec works, see this White Paper and the in-depth Video Tutorial. You can also experiment with deployment in the free Playground.


Comments


Experiment with open-appsec for Linux, Kubernetes or Kong using a free virtual lab

bottom of page