Websocket response manipulation leads to access admin panel

Introduction

During a bug bounty hunting, I discovered a subdomain hosting a seemingly normal website. However, upon closer inspection, I noticed that the application supported multiple user roles with varying levels of access privileges.

While navigating through the site and inspecting the available features, I noticed a reference to another internal domain belonging to the same organization. I accessed it and found a different web application that offered both registration and login functionalities.

As part of my typical recon workflow, I captured the login request — and to my surprise, it wasn’t a standard HTTP POST request, but rather a WebSocket connection being used for authentication — something relatively uncommon.

What is WebSocket? How is it Different from HTTP?

WebSocket is a protocol that provides persistent, full-duplex communication between the client and the server over a single TCP connection. It starts as an HTTP handshake and then upgrades the connection to WebSocket, allowing both sides to send data at any time without re-establishing the connection.

Upon inspecting the WebSocket login request, I noticed a parameter named role, which was being sent with the value visitor.

This caught my attention, so I proceeded to check the client-side JavaScript code. I opened the main.js file and searched for the keyword visitor to see what other roles might exist. It revealed three possible values for the role parameter:

• visitor
• manager
• admin

At this point, I suspected that the role might be client-controlled, and that changing its value could escalate privileges.

However, WebSocket connections typically involve many dynamic requests, making manual editing inefficient. I needed a way to automatically intercept and modify WebSocket messages.

After some research, I discovered that Burp Suite supports Match & Replace rules specifically for WebSocket traffic (via the WebSocket editor, not just regular HTTP requests).

I created a rule to replace every instance of "role":"visitor" with "role":"admin" in outgoing WebSocket messages.

I then logged in with a regular user account, and thanks to the modified role parameter, I was successfully authenticated as an admin.

Impact

This vulnerability allowed me to escalate privileges from a standard user (visitor) to an admin account without any credentials.

As an admin, I had full control over the application, including:

• Access to all user data
• The ability to delete users
• Modify or manage content
• Perform high-privilege administrative actions

Such a flaw poses a critical security risk and could lead to complete compromise of the application and its user base.