Fortimanager Cross-site Scripting

An improper neutralization of input during web page generation vulnerability [CWE-79] exists in FortiManager and FortiAnalyzer 6.0.0 all versions, 6.2.0 all versions, 6.4.0 through 6.4.8, and 7.0.0 through 7.0.4. Report templates may allow a low privilege level attacker to perform an XSS attack via posting a crafted CKeditor "protected" comment as described in CVE-2020-9281. (2022-11-02, CVE-2022-39950)

Multiple improper neutralization of input during web page generation (CWE-79) in FortiManager and FortiAnalyzer versions 7.0.0, 6.4.5 and below, 6.2.7 and below user interface, may allow a remote authenticated attacker to perform a Stored Cross Site Scripting attack (XSS) by injecting malicious payload in GET parameters. (2021-08-06, CVE-2021-32597)

An improper neutralization of script-related HTML tags in a web page in FortiManager 6.2.0, 6.2.1, 6.2.2, and 6.2.3and FortiAnalyzer 6.2.0, 6.2.1, 6.2.2, and 6.2.3 may allow an attacker to execute a cross site scripting (XSS) via the Identify Provider name field. (2020-09-24, CVE-2020-12811)

An Improper Neutralization of Script-Related HTML Tags in Fortinet FortiAnalyzer 5.6.0 and below and FortiManager 5.6.0 and below allows an attacker to send DHCP request containing malicious scripts in the HOSTNAME parameter. The malicious script code is executed while viewing the logs in FortiAnalyzer and FortiManager (with FortiAnalyzer feature enabled). (2019-05-28, CVE-2018-13375)

A Cross-site Scripting (XSS) vulnerability in Fortinet FortiManager 6.0.0, 5.6.6 and below versions allows attacker to execute HTML/javascript code via managed remote devices CLI commands by viewing the remote device CLI config installation log. (2018-06-28, CVE-2018-1351)

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>