Support Tickets Access via IDOR Vulnerability

Summary:

During my testing on https://test.support.target-site.com/, I uncovered an Insecure Direct Object Reference (IDOR) vulnerability. By manipulating the ticket_number parameter in a request to add collaborators, I gained unauthorized access to other users' tickets. This revealed sensitive personal information (PII) like usernames, phone numbers, and addresses. The target recognized the issue, and I was rewarded with both a bounty and a bonus.

While exploring the subdomain https://test.support.target-site.com/, I noticed an option to request access via email. I submitted my bugcrowdninja email and received a password reset link. After logging in, I discovered the platform was a support ticket management system where users could create, track, and comment on tickets.

One feature allowed users to add collaborators to tickets by providing their name and registered email. This caught my attention, so I intercepted the request using Burp Suite. Below is what the request looked like:

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 directly passed in the request, raising a red flag. I suspected the platform wasn’t verifying user permissions correctly. To test this, I created a second account with another email, made a new ticket, and intercepted the "add collaborator" request again.

This time, I modified the ticket_number to point to the second account’s ticket:

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

After sending the request, I checked my original account’s ticket dashboard. I was now listed as a collaborator on the second account’s ticket, giving me full access to its details, including personal information like usernames, phone numbers, and addresses.

This confirmed the presence of an IDOR vulnerability. By modifying the ticket_number in the request, any attacker could gain unauthorized access to other users' tickets. This vulnerability allowed attackers to:

• Access PII (names, addresses, phone numbers) from any user’s ticket.
• Monitor or manipulate confidential support interactions.
• Use exposed PII for phishing or social engineering attacks.

The impact was severe due to the platform’s lack of proper access control. Exploiting the issue required only basic knowledge of HTTP requests and access to the system. Here’s how the issue can be reproduced:

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

The root cause was the missing authorization checks when adding collaborators. To prevent such issues, the platform should:

• Implement strict access control to validate user permissions on every request.
• Use non-predictable ticket identifiers (like UUIDs) to make them harder to guess.
• Monitor and log unauthorized access attempts for further investigation.

This was a high-risk vulnerability due to the exposure of sensitive user data. The program team acknowledged my report, and I was rewarded with a bounty and a bonus.

This bug highlights the importance of robust access controls. Even seemingly simple features—like adding collaborators—can expose critical security flaws if not implemented securely. It’s always exciting to uncover vulnerabilities that help make systems safer.

If you have any feedback or questions, feel free to DM me on Twitter at R29k. Thanks for reading, and I’ll see you in the next write-up!