cat ~/

where I share my findings and whatnot

IDOR via Websockets

In my previous post, I shared my love for testing Insecure Direct Object Reference (IDOR) vulnerability. This time I’ll be sharing the situation where I found an IDOR in Websockets. You may want to read this write-up before you continue. But in short, I shared how I approach testing Websockets.

The target allows commenting on slides in which a user who has access to a slide can share their views about it. Knowing this, I couldn’t resist the urge to test it out. So I made a comment on a slide while also logging the requests via Burp Suite. I noticed 2 requests:

  1. A HTTP PUT request was first sent which notifies the other users of the comment (this was also vulnerable and I would write about it in an upcomming post!).
  2. And a WebSocket request with the following body.

{ "command": { "operation": [ { "p": [ "slides", 0, "comments", 12 ], "li": { "author": "authorID", "content": " My Comment", "createdAt": "creationDate" } } ], "uuid": "commentUUID", "version": 1 }, "type": "operation", "channel": { "type": "Presentation", "uuid": "slideUUID" } }

Haha! There is a lot of ID/UUIDs and I was so excited to continue testing.

Let's do this!

I immediately sent this over to Burp Repeater and replaced the authorID with that of another account I have control over. But that didn’t work 😩.

On a closer look, I realized the commentUUID could only be used once. So, I improvised and found ways I could obtain another. The easiest way was to make another comment, but this time with “intercept on” while logging requests with Burp Suite.

Then I copied the commentUUID from the HTTP PUT request and dropped both the HTTP PUT request and the Websocket request. Afterwards, I replaced the commentUUID in Burp Repeater with the one copied and sent the request. This worked and I was able to make comment as another user whether they belong to the team or not.

Let's do this!

Someone would ask, what about the other UUIDs? They were somehow not vulnerable when I tested.

Thank you for your time. And I hope you enjoyed reading this.


Dec 7, 2018 - Report Sent
Dec 7, 2018 - Comment from Triager and downgraded severity from Medium to Low
Dec 7, 2018 - Flagged the downgrade as a misunderstanding
Dec 10, 2018 - Comment from the team and report mistakenly flagged as duplicate
Dec 12, 2018 - Report state changed and severity upgraded from Low to Medium
Dec 20, 2018 - Bounty Awarded
June 13, 2019 - Fix Requested and Confirmed
Share on