What is the difference between CSRF and XSS?
The most viable way to deal with cyber threats is to remain aware of their occurrence scenarios and take early preventive measures. For security experts, client-side attack prevention is tedious and daunting as it directly puts critical data at risk.
CSRF and XSS are two such client-side attacks. They both are nefarious and have serious outcomes.
Both involve injecting ill-intent contents into the end-user's devices and are based on identical origin policies. But are they both the same? Where do they stand poles apart from each other? Let’s unearth the truth behind the CSRF v/s XSS attack.
What is XSS?
Call it XSS or Cross Site Scripting, XSS refers to a very common cybersecurity threat. Its successful implementation permits threat actors to introduce corrupted client-side scripts in user-accessible web pages. The scripts are mostly JavaScript-based and are injected into the website/web pages that a user browser mostly finds dependable.
It’s not necessary that a validated session is established between the website and end-users. Based on the process and modus-operandi of the attack, three varieties of XSS exist.
The first type of DOM XSS takes place when the user-provided input is modified via JavaScript in a highly unprotected ecosystem. Consider a scenario where an end-user captures a form value and takes the help of JavaScript to provide it in the DOM of the system. If, by any means, the attacker manages to have hold of this input, it’s possible to control the executable script.
Up next, we’ve reflected XSS, which means receiving an HTTP request by the web server and providing the same information in the output without any data protection. The entire requested information reflects in the outcome. Thus, it’s named as reflected XSS.
The last type is stored XSS, which takes place when a piece of user-generated data is first stored in any commonly used storage and is later uploaded on the webpage.
All these XSS attack varieties are capable of causing potential harm to the concerned application.
XSS In Action
The XSS occurrence possibility for an XSS attack is based on two situations. It can take place when:
- An unverified input resource provides data to the web application
- Data that is part of dynamic content is forwarded to the user without any prior verification or authentication
Either way, corrupted content reaches the intended browser and becomes a JavaScript component. It’s not necessary that only JavaScript code is a part of the code. It might feature Flash, HTML, or other code varieties as per the type of code the browser is executing at the time of an attack.
When the malicious code is processed, it can fetch any data. It’s hard to comprehend the reach of the XSS attack as cookies, users’ login data, session data, transaction data, and everything else can be obtained.
XSS Example
For better clarity on XSS processing, have a look at the real-time XSS example. Have you seen a 404 error page? It’s a very common issue, and hackers take advantage of this error to launch an XSS attack. Let’s assume that the user tries to access an unavailable page of the Unsafe.com website.
The page is likely to locate at http: //unsafe.com/non_existent_file. When a user tries to access this page, the received outcome would be Not Found:/non_existent_file.
A skilled attack planning to conduct an XSS attack will introduce corrupted code in the error page code.
When the victim sees the non-existent page of Unsafe.com, the outcome will feature an ill-intended JavaScript-based code, and when the code is processed, the hacker will be successful to obtain entire session details.
What is CSRF?
Responsible to cause troubles like alerting the client information and tons of other dangers, CSRF or Cross-Site Request Forgery occurs commonly on websites and webpages. Here, hackers don’t carry out an attack. Instead, it uses a verified user to attack a website. For instance, if a hacker wants to hack Google’s server, it won’t directly try taking over the server. Instead, it will take the help of someone verified or authenticated to access that server, deliver malicious content via the help of that user, and then take control of the aimed server.
To make it happen, it takes advantage of a pre-existing flaw in the targeted app/website and uses it against it. It uses social engineering techniques to fool authenticated users. The mandatory conditions to be fulfilled for a CSRF attack are:
- Only verified, and authenticated users are used for this exploit.
- A threat-actor can only access the aimed website after trespassing the user authentication
CSRF In Action
The process of a CSRF attack is simple. The threat actor forwards the damaging HTTP request to the aimed website. As the authenticated user accesses this site, the maliciously-designed request is automatically processed, and the hacker can view/use the user details.
CSRF Example
Consider a bank’s website that accepts fund transfers using a GET request. The code will look like this:
Now, assume that a threat actor is trying to lure a user, Josh, to transfer an amount of $5,000, to an account named Mike. Threat actors can easily modify the beneficiary details and transferred amount.
XSS vs CSRF - What Is The Difference?
Now that the basic understanding of these two vulnerabilities is clear, let’s talk about the differences that these two shares:
- XSS is a two-way attack while CSRF is only one-way. In XSS, threat actors can execute a code, receive a response, and forward it to the desired destination whereas CSRF allows attackers only to raise a corrupted HTTP request.
- XSS is JavaScript-based while CSRF is HTTP-based.
- The success of an XSS attack isn’t based on the session activation. Corrupted payloads are delivered whenever the user accesses the website. CSRF demands an active session be completed.
- The scope of CSRF attacks is limited. At max, it leads to accessing corrupted websites or clicking on malicious links. The reach of XSS is far-flung and permits attackers to do anything they want.
- About XSS vs CSRF attacks, one key point is the way they both store the trouble-causing code. The code is stored on the targeted website in an XSS attack while it’s stored on the 3rd party site for carrying out a CSRF attack.
Can CSRF Tokens Prevent XSS Attacks?
When one studies the XSS prevention technique, it’s observed that CSRF tokens are often used as a means. CSRR tokens are the auto-generated, distinct, and arbitrary values that a server-side application creates as a CSRF preventive measure. They link with the concerned HTTP requests and help in figuring out the possibility of a CSRF attack.
Along with CSRF attacks, CSRF tokens are useful to prevent some sort of XSS attacks as well.
Reflected XSS is the most common example of this. Have a look at customary reflected XSS attacks.
This is a reflected XSS vulnerable function. Now, let’s introduce a CSRF token in this function.
Introducing this CIwPZNlR4XbisJF39I8yWX9n4WNoWwXZ CSRF token will reduce the XSS attack possibility as the server will accept only those requests that are featuring CSRF tokens. This way, the CSRF token will prevent a hacker from falsifying or manipulating the cross-site request that prevents an XSS attack.
But, it’s not always a viable solution to prevent an XSS attack. For instance:
- If reflected XSS exists in a function that is not backed by a CSRF token, no one can stop it from being vulnerable.
- The presence of an XSS vulnerability anywhere on the site will allow users to take action even if the function is backed by CSRF token protection.
- You can’t use CSRF tokens to prevent stored XSS threats.
Comparison Table
Too much text seems confusing?! Well, it is. So, have a look at this crisp comparison of XSS attack vs CSRF in a table format.
FAQ
References
Subscribe for the latest news
