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:
- 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!).
- And a WebSocket request with the following body.
"content": " My Comment",
Haha! There is a lot of ID/UUIDs and I was so excited to continue testing.
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.
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.