Enterprise Server Cross-site Scripting

A stored XSS vulnerability was identified in GitHub Enterprise Server that allowed the injection of arbitrary attributes. This injection was blocked by Github's Content Security Policy (CSP). This vulnerability affected all versions of GitHub Enterprise Server prior to 3.6 and was fixed in versions 3.3.11, 3.4.6 and 3.5.3. This vulnerability was reported via the GitHub Bug Bounty program. (2022-08-02, CVE-2022-23733)

Cross Site scripting vulnerability on Micro Focus Enterprise Server and Enterprise developer, affecting all versions prior to version 5.0 Patch Update 8. The vulnerability could allow an attacker to trigger administrative actions when an administrator viewed malicious data left by the attacker (stored XSS) or followed a malicious link (reflected XSS). (2020-05-18, CVE-2020-9524)

Reflected XSS on Micro Focus Enterprise Developer and Enterprise Server, all versions prior to version 3.0 Patch Update 20, version 4.0 Patch Update 12, and version 5.0 Patch Update 2. The vulnerability could be exploited to redirect a user to a malicious page or forge certain types of web requests. (2019-10-02, CVE-2019-11651)

servlet/SnoopServlet (a servlet installed by default) in Netscape Enterprise 3.63 has reflected XSS via an arbitrary parameter=[XSS] in the query string. A remote unauthenticated attacker could potentially exploit this vulnerability to supply malicious HTML or JavaScript code to a vulnerable web application, which is then reflected back to the victim and executed by the web browser. NOTE: this product is discontinued. (2019-01-31, CVE-2018-18940)

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>