Client-side attacks are complex to mitigate as they abuse the trust between a web server and the users accessing the website. Two such client-side attacks are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), which inject malicious scripts into a target system for deeper exploitation of the tech stack or user data theft. In this article, we discuss XSS vs. CSRF attacks and learn typical attack mechanisms, prevention techniques, and differences in how they are orchestrated.
What are XSS and CSRF?
Both CSRF and XSS are client-side attacks that abuse the same-origin policy and exploit the trust relationship between the web application and the victim user.
XSS and Cross-site scripting attacks allow an attacker to compromise the interactions of legitimate users with any vulnerable application.
What is XSS?
XSS vulnerabilities occur in web applications that accept user input and use it in response without encoding or validation. The malicious users craft malicious code and submit it via the input form. The target server includes this script and its response, and the client browser executes it. Since the browser trusts the web server, it grants the malicious script access to cookies, the session token, and other sensitive client information stored locally.
XSS is a well-known attack vector, and the impacts of a successful attack typically vary for different scenarios, including:
Disclosure of user files
Malware/Trojan Horse installation
Exposure to online banking information
HTML/DOM content modification
Redirecting users to unknown websites
XSS Attack Types
XSS attacks are primarily categorized into three types:
Stored XSS Attacks/Persistent XSS/Type-I XSS
In a Stored XSS attack, the injected malicious code is permanently stored across different components of the vulnerable web application, such as the database, comment field, visitor log, message forum, etc. Every time a client visits the infected website or initiates a request to the web server, the request executes the malicious script into the user’s browser.
Blind XSS
A hybrid form of XSS attack where the attacker’s script is stored and reflected users from the backend application.
Reflected/non-persistent XSS
In reflected cross-site scripting, the malicious script is reflected off the web server, such as in a search result, an error message, or any other web server response that includes some user input. The script is delivered to the victim via an external route, such as a different website or email message. When the victim submits a form, browses the hacker’s website, or clicks on a suspicious link, the malicious script is sent to the website and then reflected in the client’s browser.
DOM-based XSS
In DOM-based cross-site scripting, the malicious script is executed as a result of modifying the victim browser’s Document Object Model environment. This attack does not change the web server’s HTTP response but alters client-side code’s execution due to DOM modifications.
What is CSRF?
Also known as session riding or the one-click attack, a Cross-site request forgery (CSRF) is a web application cyberattack that tricks victims into unknowingly performing actions on the attacker’s behalf. CSRF attacks exploit a security flaw in web applications that cannot differentiate between a bad and legitimate request within an authenticated user session.
Adversaries typically launch CSRF attacks using social engineering techniques to trick the victim user into loading a page or clicking a link containing a malicious request. The link sends a malicious request from the authenticated user’s browser to the target website. For most websites, browser requests inherently include session information such as session cookies, a valid token, or login credentials that the website associates with the user. If the authenticated user is already in an active session with the target website, the site treats the new malicious request as a valid request from the user and executes it.
CSRF Attack Types
A web application is vulnerable to Cross-Site Request Forgery if it fails to differentiate between an illegitimate and valid request. The attack is only successful if the authenticated user is in an active session with the web application.
Login CSRF Attack
Using a particular form of CSRF attack called Login CSRF attack, attackers can gain access to the victim user’s confidential and sensitive data. This attack forces an unsuspecting user to log in to an account that the hacker controls. The victim user is then tricked into adding personally identifying and sensitive information such as email addresses and credit card information to the account.
Stored CSRF Attack
A CSRF attack bundle can also be stored on the vulnerable website. The adversary can achieve a Stored CSRF attack by either performing an advanced XSS attack or storing an IFRAME or IMG tag in a field that accepts HTML. Storing the attack on the site amplifies the severity and likelihood of the attack, as the victim user is now sure to view the CSRF-loaded page and would also be naturally authenticated to the page.
Differences between CSRF VS XSS
Both CSRF and XSS are client-side attacks that abuse the same-origin policy and exploit the trust relationship between the web application and an unsuspecting user.
There are, however, a few fundamental differences between XSS and CSRF attacks, including:
XSS attacks follow a two-way attack pattern, which allows the attacker to execute a malicious script, access the response, and send follow-up sensitive data to a destination of the attacker’s choice. On the other hand, CSRF is a one-way attack mechanism, implying the attacker can only initiate the HTTP request but not retrieve the response in return for the initiated request.
CSRF attacks require the authenticated user to be in an active session, while the XSS attack does not. In an XSS attack, payloads can be stored and delivered whenever the user logs in.
CSRF attacks have a limited scope that is restricted to the actions user can perform, such as clicking a malicious link or visiting the hacker’s website. On the contrary, an XSS attack offers the execution of malicious scripts to perform any activity as per the attacker’s choice, thus widening the scope of the attack.
In XSS attacks, the malicious code is stored within the site, whereas in CSRF attacks, the malicious code is stored within third-party sites that the victim user is made to access.
XSS Example
The most common example of an XSS attack can be found when malicious users target the classic 404 error page and inject the malicious code. Let us understand this further through the attack scenario below.
Assuming the 404 error page that informs the user about the missing/non-existing page runs on code similar to:
<html>
<body>
<? php
print “Not found: ” . urldecode($_SERVER[“REQUEST_URI”]);
?>
</body>
</html>
When the user clicks a non-existent web page located at:
http://darwin.test/non_existent_file
Below response is returned:
Not found: /non_existent_file
An attacker can manipulate this error page to include malicious code, such as:
darwin.test<script>bad_payload_script</script>
As a result, the HTTP response returned now is the exact error page with the malicious JavaScript code.
Not found: /<script>bad_payload_script;</script>
Once the attacker has successfully injected malicious content, the user browser executes the injected script, granting the attacker unintended access to session information.
CSRF Example
Attackers use various vulnerable HTTP methods such as GET, PUT, DELETE and POST requests to perform CSRF attacks. An attacker may also orchestrate the exploit URL as an ordinary link and utilize these HTTP methods to transfer parameter values and execute malicious actions. The below example demonstrates a typical CSRF exploit delivered using the GET HTTP method.
Let us take a scenario where a banking web application is designed to obtain values primarily using GET requests. In such an instance, a money transfer operation would involve a similar operation as shown below:
GET darwin.com/transfer.do?acct=BOB&am… HTTP/1.1
Assuming attackers intend to trick a regular user named ‘Alice’ into transferring $50,000 to an account for MARIA, they can change the beneficiary and amount parameters in the URL as shown below:
http:darwin.com/transfer.do?acct=MARIA&…
They can then leverage social engineering techniques to trick Alice into loading this URL when logged in to her bank’s website. The malicious link can be delivered as an unsolicited email with the HTML content or as a script/exploit URL on pages Alice is likely to visit while banking online. A sample exploit URL delivered as a hidden iframe would look similar to:
<img src="darwin.com/transfer.do?acct=MARIA&…" width="0" height="0" border="0">
XSS and CSRF – FAQs
What is the difference between cross-site scripting and Javascript injection?
XSS is a client-side attack where the hacker deploys malicious scripts into a web server, which are executed by the unsuspecting user’s browser.
On the other hand, Javascript injection is a server-side attack where the hacker sends bad scripts to the server to be executed by the interpreter as if it is part of the source code.
What are some effective CSRF prevention mechanisms?
Some ways to prevent CSRF attacks include:
Using a synchronizer token pattern
Using double-submit cookies
Using HTTP standard headers to validate the origin of requests
UI-based verification such as CAPTCHA-based authorization and MFA
Using SameSite Cookies for request origin management
Use of CSRF tokens
What are some effective XSS prevention mechanisms?
Some commonly leveraged effective XSS prevention techniques include:
Enforcing Content Security Policies
Validating and filtering user input
Encoding output data
Using custom response headers (Content-Type & X-Content-Type-Options) to govern browser response interpretation
Sanitizing HTML inputs
Can CSRF tokens prevent XSS?
Reflected XSS attacks can mostly be prevented by using a practical CSRF token. When a web server adequately validates submitted CSRF tokens and rejects requests without a valid token, the practice prevents attackers from exploiting reflected XSS application vulnerabilities.
However, for other forms of XSS attack, CSRF tokens are known to be less helpful in preventing the exploit. In instances where a stored XSS vulnerability exists within the application, attackers can trick users into performing malicious actions even if such actions are CSRF protected. Attackers can also craft a script requesting the protected page to expose a valid authentication token, which can be exploited to orchestrate deeper system-level attacks and unwanted actions.
This article has already been published on crashtest-security.com/xss-vs-csrf-difference and has been authorized by Crashtest Security for a republish.