Understanding XSS: It's More Than Just a Script

#webdev #security #frontend #javascript

In this article, we will take a closer look at Cross-site Scripting (XSS) - a common frontend attack in the web world. Did you know that over 30% of websites are susceptible to XSS attacks? This isn't just a statistic; it's a wake-up call for all web developers to understand and combat one of the most common attacks.

XSS Unpacked:

XSS attacks occur when malicious scripts are sneakily injected into trusted websites. Imagine visiting your favorite news site, but unknown to you, a hacker has planted a script in the comment section. This script could steal your session cookies, giving the hacker the same access to your personal accounts as you would.

The Four Types of XSS Attacks

Stored XSS
Reflected XSS
DOM-based XSS
Blind XSS

Identifying XSS Vulnerabilities

Identifying the different types of XSS vulnerabilities is not always easy but tools used for static code analysis can scan your codebase for patterns that resemble XSS vulnerabilities. Here are a few tools I would recommend:

OWASP ZAP (Zed Attack Proxy):
An open-source web application security scanner. It's user-friendly and suitable for both beginners and experienced penetration testers.
XSStrike:
A Python-based advanced XSS detection suite. It is known for its ability to detect and exploit XSS vulnerabilities with high accuracy.
Acunetix:
A fully automated web vulnerability scanner that detects and reports on over 4500 web application vulnerabilities including all variants of XSS.

Along with tools, its also important to put in place processes for regular security audits and awareness of common coding mistakes (like failing to validate user input).

A Walkthrough of an XSS Attack using TinyMCE

By default, TinyMCE filters content such as scripts from the editor. If you are using a TinyMCE version before 6.4, the editor used the DOMPurify library to sanitize HTML content when it is inserted into the editor in order to remove unsafe tags & attributes. However, customers in some situations have found that the HTML sanitization from the DOMPurify library is changing their content in undesired ways.

To address this issue, TinyMCE 6.4.1 and later versions have added a new xss_sanitization: boolean editor option. This option is enabled by default which enables sanitization and can be set to false to disable sanitization. If a customer wishes to prevent their content from being modified by the sanitization, they can now set this option to false. It is important to note that disabling sanitization introduces potential security issues, especially if the server-side XSS sanitization is weak or non-existent. Using this option therefore not recommended.

Let's walkthrough of an XSS attack in a scenario where TinyMCE's xss_sanitization feature is turned off and there aren't protocols in place to protect the editor. Let's consider a typical web application that uses TinyMCE for content input, like a blog or a forum, and explore how an XSS attack could be executed and subsequently mitigated.

Application Context: A blog platform where users can write posts using TinyMCE editor.

Assumption: The TinyMCE editor's xss_sanitization feature is disabled, either intentionally for flexibility or due to an oversight.

The Attack Walkthrough

1. Attacker's Action:

An attacker writes a blog post and includes a malicious script in the content. For example, they could insert a JavaScript snippet like

<script>execute('XSS');</script>

2. Content Submission:

The attacker submits the post. Since xss_sanitization is off, the script is not removed or neutralized by TinyMCE.

3. Storing the Data:

The application saves the post content to the database without additional sanitization.

When another user views the attacker's post, the malicious script executes in their browser. This could lead to various malicious outcomes, such as cookie stealing, session hijacking, or redirecting the user to a harmful site.

How to solve this in TinyMCE:

Even with TinyMCE's xss_sanitization turned off, you can sanitize the input using valid_elements and invalid_elements before storing it in the database:

When initializing TinyMCE, you can configure it to limit the types of tags and attributes that are allowed. This helps in reducing the risk of XSS by filtering out unwanted scripts and tags:

tinymce.init({
    selector: 'textarea',
    valid_elements: 'p,h1,h2,h3,h4,h5,h6,strong,em,span,ul,ol,li,a[href|target]',
    invalid_elements: 'script,iframe,object,embed',
    // Further configuration...
});

valid_elements: Specifies the tags and attributes that are allowed. For example, a[href|target] allows <a> tags with href and target attributes.
invalid_elements: Defines tags that are completely disallowed, such as script.

This is a basic example. In a real-world application, you would need more robust sanitization and validation depending on your specific use case. Always test your sanitization logic thoroughly to ensure it handles various XSS attack vectors.Consider using more advanced server-side libraries for sanitization if your application's security requirements are high.

Happy Coding!