Attacks like Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) may operate quietly, but they can leak sensitive data, user sessions and results in significant data breaches. The ideal method to tackle such cyber attacks effectively is, by implementing proactive security measures from the start. XSS and CSRF vulnerabilities could pose risks to security and trustworthiness of websites that allows unauthorized access and data theft.

The possibility of such vulnerabilities is the reason why web applications must be secured by strong security measures. Recently in 2024, Ticketmaster breach exposed the data of 560 million customers which highlights the severe damages caused by such vulnerabilities. This cyberattack also highlights the immediate need for DevSecOps teams to focus on security during the software development process by becoming fully aware of threats like XSS and CSRF. If these attacks are not addressed properly , it could result in major consequences and damages.

This blog explores what is XSS and CSRF, their differences and offers insights on how to prevent them.

What is Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a web security vulnerability or threat that gives chance for attackers to inject malicious scripts into trusted websites. Attackers can inject JavaScript or other code that is later executed in the browser of the user who views the compromised page. When a website fails to properly validate the user input, it can lead to theft of sensitive information, session hijacking, or manipulation of website content.

Example of Cross-Site Scripting (XSS)

If a website displays a message from a URL parameter without proper sanitization:

text

https://insecure-website.com/status?message=Hello+world.

<p>Status: All is well.</p>

An attacker could create a URL for instance:

text

https://insecure-website.com/status?message=<script>alert('Hacked!')</script>

In all cases, XSS exploits the trust a user has in a website, which allows attackers to run code as if it came from the trusted source

How Does Cross-Site Scripting (XSS) Work

Image source: Virtual cyber labs

Here’s a breakdown on how attackers perform Cross-site scripting (XSS) attack:

1. The attacker identifies a website page, that shows user input such as a search result, profile page or comment section.

2. Next, the attacker creates a malicious payload (e.g., <script>alert('XSS')</script>) and presents it through a URL parameter, form field, or other input.

3. If the application does not detect and sanitize this input, the script will be included in the page’s HTML output.

4. When other user visits the page, their browser will execute the injected script which believes it to be legitimate content from the trusted website.

5. The attacker’s script will be able to steal or retrieve cookies, hijack user sessions, redirect users, deface the site, or perform actions on behalf of the user.

XSS attacks can be categorized as:

1. Reflected XSS: The malicious script comes from the current request (like the example above).

2. Stored XSS: The malicious script is saved on the server (e.g., in a comment or profile), and affects every user who views the data.

3. DOM-based XSS: The vulnerability exists in client-side code that dynamically injects malicious data into the page.

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is a type of cyberattack where an attacker manipulates an authenticated user to perform unknowing actions on a website application without their consent. This attack exploits the trust that a web application has in the user's browser and automatically includes user credentials like session cookies with each request.

Example of Cross-Site Request Forgery (CSRF)

For instance, when a user is logged into his online banking account at bank.com, he can unknowingly visit a malicious website while still logged in. That malicious site secretly requests that his bank.com transfer money without his consent.

text

http://bank.com/fundtransfer?acct=224224&amount=75000

If the user is logged in and opens a webpage that contains this code, their email address will be changed to the attacker's email without their knowledge.

How Does Cross-Site Request Forgery (CSRF) Work

Image source: Indusface

Here’s a breakdown on how attackers conduct Cross-Site Request Forgery (CSRF) attack:

1. When user logs in to a trusted website (e.g., a banking site, social media website), and the site issues authentication credentials (like cookies) that the browser stores for subsequent requests.

2. Next, attacker creates a malicious website, email, or message that contains a link, hidden form, or script which is designed to trigger an action from the user on the target site (such as transferring funds or changing account details).

3. The user visits the malicious site or clicks the attacker’s link through social engineering methods, while still authenticated to the website.

4. The user's browser still holds the authentication cookies from the trusted site but also automatically includes these credentials in any requests made to the target site, even if the request is originated from the attacker’s site.

5. The target web application receives the request, verifies the valid credentials, and continues to process the action believing it to be from a real user, without distinguishing it as compromised and forged.

Difference Between XSS and CSRF

Here are some differences between XSS and CSRI:

Can CSRF Tokens Prevent XSS Attacks?

In case, if a a web application enforces CSRF validation on the server side that, requires a valid CSRF token for all requests, and that the server reliably returns a simple, non-exploitable error message when the token is missing, with no reflected attack vectors. This makes it look like appropriate measures are in place to protect the CSRF token from being stolen or guessed

It would not be accurate to conclude that CSRF tokens alone prevent reflected XSS attacks.

The reasoning is as follows:

• CSRF tokens are specifically created to mitigate Cross-Site Request Forgery by ensuring that requests stem from a genuine, authorized user.

• Reflected XSS vulnerabilities happens when an untrusted user input is included directly in a server response without proper sanitization or output encoding. The presence or absence of a CSRF token does not impact whether input is safely handled or reflected.

• Even if the server does not show any content if a CSRF token is absent, if a token is present and the application is not properly handled and it reflects other user-supplied input (e.g., query parameters, form fields) without proper output encoding or escaping, reflected XSS remains possible.

Hence, the prevention of reflected XSS mainly depends on accurate input validation and output encoding, not on CSRF token validation.

While the described CSRF token mechanism might incidentally minimize the attack surface by limiting when reflections occur, It does not fundamentally remove the risk of reflected XSS. Separate and dedicated defenses such as output encoding, input sanitization and Content Security Policy (CSP) are necessary to prevent XSS vulnerabilities.

Final Thoughts

Protecting your APIs from XSS and CSRF attacks is very crucial in the modern digital sphere. Akto API security platform provides all round security for Modern AppSec teams. It conducts real-time security testing, automatically discovers APIs, and detects vulnerabilities like XSS and CSRF. Apart from this, Akto has a large library of over 800+ security tests. Akto performs a thorough assessment of your API endpoints and effortlessly integrates into CI/CD pipeline. Akto assists in continuous security monitoring throughout the development lifecycle.

Start securing your APIs today with Akto reliable security solutions. Book a demo today!