IDOR: Unauthorized Access to Support Tickets

During testing on a support subdomain, I uncovered an Insecure Direct Object Reference (IDOR). By manipulating the ticket_number parameter in a request to add collaborators, I gained unauthorized access to other users' tickets, exposing sensitive personal information like usernames, phone numbers and addresses. The target recognized the issue and rewarded me with both a bounty and a bonus.

The target

While exploring the subdomain, I noticed an option to request access via email. I submitted my bugcrowdninja email and received a password reset link. After logging in, I found the platform was a support ticket management system, where users create, track, and comment on tickets.

The feature

One feature let users add collaborators to a ticket by providing their name and registered email. That caught my attention, so I intercepted the request in Burp Suite. Here's what it looked like:

add-collaborator request
POST /add-collaborator HTTP/1.1
Host: test.support.target-site.com
Content-Type: application/json

{
  "ticket_number": 12345,
  "email": "bugcrowdninja@example.com"
}

The ticket_number was passed directly in the request, which raised a red flag, the platform probably wasn't verifying permissions correctly. To test it, I created a second account with another email, made a new ticket, and intercepted the add-collaborator request again. This time I changed the ticket_number to point at the second account's ticket:

modified request
{
  "ticket_number": 67890,
  "email": "bugcrowdninja@example.com"
}

Confirming the IDOR

After sending it, I checked my original account's ticket dashboard. I was now listed as a collaborator on the second account's ticket, with full access to its details, including personal information like usernames, phone numbers and addresses. That confirmed the IDOR: by modifying the ticket_number, any attacker could reach other users' tickets.

Reproduction

1. Log in to the support platform with any valid account.
2. Create a new support ticket.
3. Use Burp Suite (or any proxy) to intercept the add-collaborator request.
4. Modify ticket_number to match the ID of another user's ticket.
5. Send the modified request and confirm you've been added to that user's ticket.

Root cause and fixes

The root cause was missing authorization checks when adding collaborators. Exploiting it required only basic knowledge of HTTP requests and access to the system. To prevent this, the platform should:

• Enforce strict access control, validating the user's permissions on every request.
• Use non-predictable ticket identifiers like UUIDs so they can't be guessed.
• Log and monitor unauthorized access attempts for further investigation.

The impact here was significant, given the exposure of sensitive user data. The program team acknowledged the report and rewarded me with a bounty and a bonus. This one is a reminder that even simple features, like adding collaborators, can expose critical flaws when access control isn't built in properly.

---

Any feedback or questions? DM me on Twitter @R29k_. Thanks for reading, see you in the next one.