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?
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.
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
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.
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.
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.
Consider a bank’s website that accepts fund transfers using a GET request. The code will look like this:
GET http: //banking.com/transfer.do?acct=John&amount=1000 HTTP/1.1
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.
GET http: //banking.com/transfer.do?acct=Mike&amount=5000
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.
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.
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.
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.
The corrupted script is introduced in the client-specific site script.
The website user is tricked in a manner that s/he end-up injecting corrupted HTTP requests to the aimed website without knowing the outcome.
Random data is introduced bit by bit and is not authenticated.
Success of the attack hinges on the ability and features of the browser. If the browser is capable of processing the attack bundle, the CSRF attack will become successful.
The targeted website receives the corrupted code and processes it.
The website doesn’t store the trouble-causing code as it’s stored on 3rd party websites.
The presence of XSS vulnerability paves the path for CSRF attack as well.
CSRF attack doesn’t mean that the targeted website is prone for XSS attack as well.
The outcome is pretty nefarious and harmful
CSRF attack isn’t too destructive.
The attacker is capable of doing everything s/he wants after a successful attempt.
This exploit is controlled, and hackers can do damage that falls under the capacity of URL.