Mass Assignment leads to Stored XSS in librenms/librenms
Reported on
Sep 21st 2022
Description
The application is vulnerable to mass assignment in the User object. A user is able to enable their own account and change their username. The username is not properly sanitized in the admin user overview, leading to a stored XSS attack.
Proof of Concept
Steps to reproduce:
1. Log in with an admin account.
2. Create a test user with the user role `Normal` & enable that user
3. Log in with the test user in a separate browser or private browser window
4. In the test user session, go to `/preferences`
5. Change the test user's password and log the request in Burp. The request should be an HTTP POST request to the endpoint `/users/<user_id>`
6. Send the request to Burp Repeater. Modify the request body to contain the values `enabled=1&username=<script>alert(document.location)</script>` & send it
7. In the admin sessions, go to `/users` to trigger the XSS
PoC request:
POST /users/4 HTTP/1.1
[...]
Cookie: laravel_session=[...]; XSRF-TOKEN=[...]
_method=PATCH&_token=e0NktnwRhcR1Jh2xpex25AFZ67PCsR4X72T3rd0F&enabled=1&username=<script>alert(document.location)</script>
Screenshot 1 (Manipulated Request)
Screenshot 2 (XSS)
Impact
A user is able to enable their own account if it was disabled by an admin while the user still holds a valid session. Moreover, the username is not properly sanitized in the admin user overview. This enables an XSS attack that enables an attacker with a low privilege user to execute arbitrary JavaScript in the context of an admin's account.
Occurrences
UserController.php L183
A user should not be able to enable their own account. If editing of the other fields is intended, the username should be properly sanitized to avoid the XSS vulnerability.
Hi @maintainer, thanks for validating this report as well as the other three reports. Can we disclose these reports and maybe also go for CVEs? :)