Read Edit Delete Non Sensitive Information

Read/Edit/Delete Non-Sensitive Information

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 can be leveraged by an attacker to bypass access controls, manipulate and read non-sensitive information.

Business Impact

IDOR can result in 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}}

An attacker could leverage this IDOR vulnerability to extract data by using the following payload:

{{payload}}

The following screenshot(s) demonstrate(s) this vulnerability:

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

Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

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