This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Z-blogphp
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments. (2018-10-16, CVE-2018-18381)
** DISPUTED ** An issue was discovered in Z-BlogPHP 2.0.0. There is a persistent XSS that allows remote attackers to inject arbitrary web script or HTML into background web site settings via the "copyright information office" field. NOTE: the vendor indicates that the product was not intended to block this type of XSS by a user with the admin privilege. (2018-05-16, CVE-2018-11208)
** DISPUTED ** Z-BlogPHP 1.5.2 has a stored Cross Site Scripting Vulnerability exploitable by an administrator who navigates to "Web site settings --> Basic setting --> Website title" and enters an XSS payload via the zb_system/cmd.php ZC_BLOG_NAME parameter. NOTE: the vendor disputes the security relevance, noting it is "just a functional bug." (2018-05-02, CVE-2018-10680)
Z-BlogPHP 1.5.1 has XSS via the zb_users/plugin/AppCentre/plugin_edit.php app_id parameter. The component must be accessed directly by an administrator, or through CSRF. (2018-04-16, CVE-2018-9169)
** DISPUTED ** In Z-BlogPHP 1.5.1.1740, cmd.php has XSS via the ZC_BLOG_SUBNAME parameter or ZC_UPLOAD_FILETYPE parameter. NOTE: the software maintainer disputes that this is a vulnerability. (2018-03-06, CVE-2018-7736)
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>