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.
{
"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.
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.