What Is IDOR Vulnerability?
There can be many variables such as "id", "pid", "uid" and so on the app. Although these values are mostly seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete objects of other users by changing the values. This vulnerability is called IDOR.
First, you should understand the application flow developed by software developers. When the logged-in user logs into the web/mobile application, all module functions and sub-module functions must be understood. It is also important to remember that this vulnerability is as severe in security testing as XSS, CSRF, and some type of vulnerability that is not easily discovered (automatic testing or manual testing).
The IDOR vulnerability is shown in the image below, between user and server.
This article will cover the following topics:
How to find the injection point where IDOR vulnerabilities can be found?
Some seemingly simple IDOR vulnerability tips and the best experiences we've encountered.
Precautions to consider when testing the IDOR vulnerability.
How are basic authorization controls maintained?
Effective And Quick IDOR Vulnerability Testing
You can use the browser's incognito tab to quickly test IDOR vulnerabilities. Therefore, when you use the normal tab as the normal user, you can use the incognito tab as offensive. This will ensure that you do not log out.
You can use Burp Suite's HTTP History tab to check all requests. HTTP History feature showing all traffic between the device (browser, phone, tablet) and the application's server. Also, you can use Burp Suite's scope feature for quick testing. The scope feature can be useful for making a list of goals, and the scope feature allows only relevant data to be shown for your test scope.
You can edit this added scope value according to the given scope as follows.
Finally, you need to do the following filtering by selecting "Show only in-scope items" in HTTP History tab.
Capture All Requests
When performing IDOR vulnerability testing, you basically need to fulfill all requests that the web/mobile application needs to be created. Because if you have changed something in the application, you can use this state to create other requests. WSDL file, Swagger page etc. If you have all the API requests of the app and it runs regularly, then you're lucky. You can use it and it will provide you convenience for IDOR testing.
In one program, the web application included an in-app messaging system. The user can send messages to other users and add other users to their own messages. When the user tries to access one of his messages, a request goes to "/messages/5955" and his message ID looks like "5955". Similarly, when trying to access another user's message by requesting "/messages/5955", the message was not accessed. When the user wants to add another user to his/her message, a request as appears below.
Kod:
[COLOR="PaleGreen"]POST/messages/5955/invite HTTP/1.1Host: örneksite.comUser-Browser: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10.12; rv: 52.0) Gecko / 20100101 Firefox / 52.0 accept: * / * X-requested-with : XMLHttpRequestCookie: my_cookiesConnection: closeuser = testaccount2[/COLOR]And when this request is examined, the user can add himself/herself to the messages of other users and access all messages.
Also, a good understanding of the roles in the application is required to identify the IDOR vulnerability. It will be very useful at the vulnerability detection phase if you know what a role should or should not do. So first you have to understand the application very well.
How Are The Injection Points Found?
As I mentioned earlier, you can find many requests for IDOR vulnerability testing using all the features of the app. When API endpoints are not provided in IDOR vulnerability tests, .html source code or .js files are useful. These files often contain interesting things and ajax requests. IDOR vulnerability testing can be performed using requests presented in these files. This may be requests made earlier by the application and possible future requests.
If you're lucky, you can only see requests that an authorized admin user should see in javascript files. Therefore, source code and especially javascript files should be well analyzed.
You can also search for the old version of the web application on "archive.org" and find useful requests in old javascript files or search for requests in search engines using dorks.
In some cases identity values are not unique like 1, 2, 3, 100, 1000 etc., these id values can be encoded or hash values. If you encounter an encoded value, you can test the IDOR vulnerability by decoding the encoded value. If you come across a hash value, you should test whether the hash value is accessible or predictable. In another case, you can access the hash value from the "Referring" header so that these scenarios can be replicated.
For example, you cannot access another user's objects, but you can find the hash ID value of the object in the source code of the object page, you can find the hash ID of the object in an in-app message from the victim user (this reduces the impact error). So you can create 2 test accounts as X and Y, then try out X's mixed identity value in Y's Burp history requests.
On another point, some app requests can scare you. For example, SmartSheet's request with multiple parameters seems too complex.
If you want to find the injection point in this request, you can use Burp Suite's comparison tool. You should right click on the request and select "Send to Comparator". You can then create the same request to use another object and send it to the comparator.
When you visit the comparison tool and click the "Words" button, a window will open showing the changing points.
You can use the same method for HTTP responses and examine their differences.
Source:https://www.turkhackteam.org/web-server-guvenligi/1916084-idor-zafiyeti-nedir.html
Translator: Dolyetyus
