This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Jazz For Service Management
IBM Jazz for Service Management is vulnerable to stored cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 231381. (2022-09-28, CVE-2022-35722)
IBM Tivoli Netcool/OMNIbus_GUI and IBM Jazz for Service Management 1.1.3.10 is vulnerable to stored cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. (2021-09-23, CVE-2021-29800)
IBM Jazz for Service Management 3.13 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 172123. (2020-03-23, CVE-2019-4718)
IBM Jazz for Service Management 1.1.3 is vulnerable to HTTP header injection, caused by incorrect trust in the HTTP Host header during caching. By sending a specially crafted HTTP GET request, a remote attacker could exploit this vulnerability to inject arbitrary HTTP headers, which will allow the attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking. IBM X-force ID: 158976. (2019-09-05, CVE-2019-4186)
Why Cross-site Scripting can be dangerous
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>