Subsonic Cross-site Scripting

An issue was discovered in Subsonic 6.1.1. The general settings are affected by two stored cross-site scripting vulnerabilities in the title and subtitle parameters to generalSettings.view that could be used to steal session information of a victim. (2018-09-21, CVE-2018-14690)

An issue was discovered in Subsonic 6.1.1. The music tags feature is affected by three stored cross-site scripting vulnerabilities in the c0-param2, c0-param3, and c0-param4 parameters to dwr/call/plaincall/tagService.setTags.dwr that could be used to steal session information of a victim. (2018-09-21, CVE-2018-14691)

An issue was discovered in Subsonic 6.1.1. The radio settings are affected by three stored cross-site scripting vulnerabilities in the name[x], streamUrl[x], homepageUrl[x] parameters (where x is an integer) to internetRadioSettings.view that could be used to steal session information of a victim. (2018-09-21, CVE-2018-14688)

An issue was discovered in Subsonic 6.1.1. The transcoding settings are affected by five stored cross-site scripting vulnerabilities in the name[x], sourceformats[x], targetFormat[x], step1[x], and step2[x] parameters (where x is an integer) to transcodingSettings.view that could be used to steal session information of a victim. (2018-09-21, CVE-2018-14689)

An XSS issue was discovered in Subsonic Media Server 6.1.1. The podcast subscription form is affected by a stored XSS vulnerability in the add parameter to podcastReceiverAdmin.view; no administrator access is required. By injecting a JavaScript payload, this flaw could be used to manipulate a user's session, or elevate privileges by targeting an administrative user. (2018-09-21, CVE-2018-9282)

Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.

The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:

https://server.com/confirmation?message=Transaction+Complete

what results in:

<span>Confirmation: Transaction Complete</span>

In that case the message can be modified to become a valid Javascript code, e.g.:

https://server.com/confirmation?message=<script>dangerous javascript code here</script>

and it will be executed locally by the user's browser with full access to the user's personal application/browser data:

<span>Confirmation: <script>dangerous javascript code here</script></span>