WebSockets Cross-Site Scripting Vulnerability

[eaneatfruit]

Description

The Sporeas application currently implements input sanitization on the client-side. This is the most common input where a user will submit their input. Very little restriction is done on the wire. An attacker may submit their cross-site scripting payloads through a proxy. Given that it is possible to interfere with an existing session, attackers may use this to key log a user's browser, steal their cookies, redirect users, and plant crypto miners. For demonstration purposes, a redirect payload was used.

Risk

High

Impact

Potential Church Service Disruption

Affected Assets

• https://service.tjcav.com/socket.io/?EIO=3&transport=websocket&sid=e6385e3df6544b6e84962997d0d44f15 [title, ch_title, hymn, book, verse parameters]

Evidence

As proof of concept, the below screenshot demonstrates an error on the client-side that prohibits special character input and typical XSS payloads.

On the network level, it is possible to submit an alert box by modifying the raw web socket request as shown below.

This is the resultant behaviour on the presentation tab of the browser which shows the triggered XSS.

An attacker can simply issue a redirect request to disrupt an ordinary church service. It is also possible to issue requests to drop malware on AV personnel.

The resultant browser would carry the live stream to a rickroll.

Remediation

It is important not only to sanitize input on the client-side. When this is processed by the server, it is important for the server to also perform output encoding on special character so that it would not execute on a browser.

[hchiam]

@eaneatfruit lol rickroll

[hchiam]

Will need to investigate the python code.

Or maybe we could refactor the frontend so we can use CSP to block all inline scripts

Or both.

[hchiam]

Closing for now until get further feedback.