Read Edit Delete Sensitive Information Iterable Object Identifiers

Read/Edit/Delete Sensitive Information/Iterable Object Identifiers

Overview of the Vulnerability

Insecure Direct Object Reference (IDOR) occurs when there are no access control checks to verify if a request to interact with a resource is valid. An IDOR vulnerability within this application allows an attacker to read Personally Identifiable Information (PII) by iterating through object identifiers.

Business Impact

IDOR can lead to reputational damage for the business through the impact to customers’ trust. The severity of the impact to the business is dependent on the sensitivity of the data being stored in, and transmitted by the application.

Steps to Reproduce

1. Use a browser to navigate to: {{URL}}

2. Login to User Account A

3. In the URL bar, modify the parameter to a different value:

{{eg.https://example.com/parameter(UserAccountB)}}

1. Observe that the application displays information of User Account B, as seen in the screenshot below:

{{screenshot}}

Proof of Concept (PoC)

Below is a screenshot demonstrating the exposed object executing:

{{screenshot}}

A malicious attacker could leverage this IDOR vulnerability to read PII by using the following payload:

{{payload}}

The following screenshot(s) demonstrate(s) this additional impact:

{{screenshot}}

Guidance

Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed triage time and result in faster rewards. Your submission must include evidence of the vulnerability and not be theoretical in nature.

To demonstrate access to sensitive information, self register two separate accounts and clearly demonstrate how you view the "victim" account information from the "attacker" account.

If identified, do not access or attempt to access sensitive information. Do not access Personally Identifiable Information (PII) as there are legal consequences to doing so.

Recommendation(s)

Preventing IDOR involves ensuring that each user accessible object is sufficiently protected. When an object is requested by an untrusted source, each request should pass through an access control check to ensure that the user has authorization to access that object.

These authorization checks should also occur when a known user requests a resource so that the users can only access data from within their intended permissions group.

Additionally, hash functions and hashed strings should be used to map an object instead of a direct ID, so that it is not a predictable value and easily guessed.

For more information, refer to the following resource:

• https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html