Did you know that you can navigate the posts by swiping left and right?

IDOR Story - 1

07 Mar 2020 . category: web-application-security . Comments
#bugbounty #appsec

DIGEST

We always have some curiosity to get private programs on Bug bounty platforms. This IDOR Story-1 going to have a small brief about the bug which helped me to enumerate the list of private programs on one of the private bug bounty platform.

IDOR

IDOR is a kind of Access control vulnerability. It’s also more vulnerable as like other high severe issues. Its severity will get change based on the scenario and attack place.

CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Root Cause:

An unprotected API endpoint without any access control validation.

POC:

A platform had many different programs. When I click on any program that takes me to a different page using the below-mentioned endpoint.

https://sub.retacted.com/api/xxx/yyy/programs/9999

Whenever I changed that program number from “9999” to any other number, the application always took me to the custom error page.

After enumeration, I found different API end Points which is used to retrive the data of every programs,

https://sub.retacted.com/api/xxx/yyy/organizations/9999/logo

Luckily this API endpoint is unprotected and allowed me to enumerate the logo of all the private and public programs and other details too ;)

IDOR-1

Solution:

1. The authentication and authorization policies are role based, to minimize the effort required to maintain these policies.

2. The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.

3. If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

4. Default should be access denial - if user has access -> then allow.

5. Avoid exposing your private object references to users whenever possible, such as primary keys or filenames.

6. Instead of sending primary keys (like code in the above scenario) in URL, better to use session to send such a kind of information.

7. This should be implemented for all the parameters used across all the pages in the application.

8. Validate any private object references extensively with an "accept known good" approach.

9. Verify authorization to all referenced objects.

Reference:

https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html


Me

Viswanathan is an awesome person. He lives in Tamilnadu, India, where he works on multiple Web, API and mobile application Vulnerability Assessment and Penetration Testing (VAPT) projects. In his spare time, Viswa likes to eat Chicken Briyani.