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.