IDOR leads to deleting comments in posts

Hello, bug hunters, security professionals, and loyal readers of Saello Write Up!

Today, I’m sharing my finding: an Insecure Direct Object Reference (IDOR) vulnerability on a web application (specific name withheld for ethical disclosure) that allowed for unauthorized comment deletion. This bug enabled an attacker to delete other users’ comments without proper authorization.

Summary

This vulnerability allowed an unauthorized user to delete any comment on the platform by manipulating a direct object reference (comment_id) within an HTTP request. The system failed to perform adequate authorization checks to verify if the requesting user was the legitimate owner of the comment being targeted for deletion, leading to a direct violation of content integrity and unauthorized content censorship.

Steps to Reproduce

Here are the precise steps that led to the successful unauthorized comment deletion:

1. Create an account at https://website.com/.
2. Navigate to a post that has a comment you made. Initiate the process to delete your own comment. Use a proxy tool (e.g., Burp Suite) to intercept the HTTP request sent for this deletion. The request will typically look like this:

POST /api/v1/comments/delete HTTP/1.1
Host: platform-x.com
Authorization: Bearer [USER_TOKEN]
Content-Type: application/json

{
    "comment_id": "123"
}

3. Send this request to the Repeater tab in your proxy tool for manipulation.
4. Browse the platform and locate a comment made by another user. Identify the comment_id of the target comment (e.g., 456).
5. In the Repeater tab, modify the comment_id value from your own comment ID (123) to the target user’s comment ID (456)

POST /api/v1/comments/delete HTTP/1.1
Host: platform-x.com
Authorization: Bearer [USER_TOKEN]
Content-Type: application/json

{
    "comment_id": "456"
}

6. Send this modified request.
7. Navigate back to the post where the targeted comment (comment_id:456) was located.
8. Observe that the comment with ID 456 has been successfully deleted, even though the request originated from an account that did not own the comment.

Impact of the Vulnerability

The ability to perform unauthorized comment deletion, while seemingly minor, carries significant consequences:

• Unauthorized Content Censorship: Attackers can selectively remove comments they dislike, comments containing important information, or critical commentary, thereby manipulating public discourse and potentially suppressing free speech.
• Data Integrity Compromise: The integrity and consistency of content within the platform’s database are compromised, as data can be altered by unauthorized parties.
• Platform Credibility and Trust Erosion: Users will lose trust in the platform if their comments can vanish without explanation or their consent, leading to decreased user engagement and potential abandonment of the service.
• Potential for Wider Abuse: An IDOR in one feature often indicates broader weaknesses in the application’s access control mechanisms, suggesting that similar vulnerabilities might exist in more critical functionalities, potentially leading to more severe compromises.

Recommendations

To address and mitigate this IDOR vulnerability, the following crucial steps should be implemented:

1. Strict Backend Authorization Validation:
   • Whenever there is a request to access, modify, or delete an object (such as a comment), the server must always explicitly verify whether the user making the request has legitimate rights to that specific object.
   • For the comment deletion endpoint, the server should retrieve the comment_id from the request, then query the database to determine the user_id associated with that comment. This retrieved user_id must then be compared against the user_id of the currently authenticated session. If they do not match (and the user is not an administrator or moderator with explicit deletion rights), the request should be rejected (e.g., with a 403 Forbidden response).
2. Avoid Using Easily Guessable Direct References (Indirect References):
   • Where feasible, avoid exposing sequential or easily guessable internal database IDs in URLs or request parameters.
   • Instead, consider using Indirect Object References such as UUIDs (Universally Unique Identifiers), cryptographically secure hashes, or mapped IDs that are unique per user session. This makes it significantly harder for an attacker to guess valid IDs of other users’ objects.
3. Implement Role-Based Access Control (RBAC):
   • If the application has different user roles (e.g., standard user, moderator, administrator), ensure that the authorization logic explicitly accounts for these roles. A moderator or admin might have the right to delete any comment, but a standard user should only be able to delete their own.

By diligently implementing these recommendations, the application can establish robust defenses against IDOR attacks, safeguarding data integrity and reinforcing user trust.

Conclusion

Findings like this serve as a critical reminder that even in seemingly benign features, robust security validation is paramount. Usage limitations, when improperly enforced, can lead to resource abuse and undermine the intended functionality and fairness of a system. Even with seemingly well-defined systems of roles and access rights, critical vulnerabilities can still emerge if validation is not performed comprehensively at every layer.

Stay vigilant and happy hunting!

Regards,

Saello