Impersonation Vulnerability in Websocket Chat


I’ve identified a potential security vulnerability regarding websocket impersonation in our chat system. By capturing and modifying the channel_id value from a websocket message, it’s possible to impersonate another user. How can avoid it?

// If problem, please fill out the below. If question, please delete.


// What version of the SDK are you using?

[Reproduction Steps]

1- Launch an interceptor tool like Burp.

2- Assume three users (user1, user2, user3) , let’s start a chat from user1 to user2 with text = “Hello from user1 to user2”

3- Capture the websocket message in Burp. An example message

MESG{"channel_id":123123123,"scrap_id":"","user":{"name":"Test","image":"","require_auth_for_profile_image":false,"guest_id":"456","id":456456,"role":"","metadata":{},"is_bot":false,"is_ai_bot":false,"is_active":true},"silent":false,"check_reactions":false,"is_op_msg":false,"is_guest_msg":true,"data":"{\"isDeepLink\":false,\"sender\":{\"id\":\"456\",\"name\":\"usernametest\"}}","sts":169807123123,"channel_url":"sendbird_group_channel_123123_123123123","channel_type":"group","is_super":false,"mention_type":"users","mentioned_users":[],"message_events":{"send_push_notification":"receivers","update_unread_count":true,"update_mention_count":true,"update_last_message":true},"message_retention_hour":-1,"request_id":"123123123","translations":{},"custom_type":"","is_removed":false,"last_updated_at":1698072673333,"message":"Hello from user1 to user2","msg_id":789789,"ts":1698072644444,"req_id":"456456456"}

4- Send that websocket message to repeater

5- Confirm that user2 has received user1 message.

6- Start a chat from user2 to user3 sending e.g. “Hello from user2 to user3”

7- Capture that websocket message using Burp and note the channel_id from user2 to user3.

8- In Burp’s repeater tool, replace the original channel_id (from step 4) with the new channel_id from step 8. Modify the message content if desired, then resend.

9- user2 will receive a message seemingly from user3 , even though user3 did not send it.



[Current impact]

It’s critical.


Thank you for reporting this issue. It’s quite an interesting concept because its not one that is long lived, given a refresh would fix the issue. I’ll have to bring this up to our Engineering team as I don’t think this is a critical issue given the necessary steps to intercept the WSS connection.

Thanks for your answer, is there a way to encrypt those parameters like channel_id to avoid interceptors? Or a better way to establish a 1vs1 chat ?

I was thinking about the vulnerability and it could be critical because channel_id is autoincremental, so you can increase one by one the channel_id (and also the req_id) and start a big spam.
And i dont understand when you say “given a refresh would fix the issue” because if i refresh the chat or close and open the app, the messages still there.

Hi, is there a better way to create one-one chats to avoid this vulnerability? thanks!