Understanding IDOR Vulnerability
There can be many variables in the application such as “id”, “pid”, “uid”. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This vulnerability is called IDOR.
First, it needs to understand the application flow developed by the software developers. All the modules functions and their sub-modules functions need to be understood when the logged-in user into the web/mobile application. It is also important to remember that this vulnerability is as severe as XSS, CSRF in security testing and as a type of vulnerability that is not easily discovered (automatized testing or manual testing).
Effective & fast IDOR vulnerability test
You can use the browser’s secret tab to quickly practically test IDOR vulnerabilities. So, when you use the regular tab as a normal user, you can use the secret tab as an attacker. This will ensure that you don’t logout.
You can use Burp Suite’s HTTP History tab for checking all of requests. The HTTP History feature that shows all the traffic between the device (browser, phone, tablet) and the application’s server. Also, you can use Burp Suite’s scope feature for fast testing. Because the scope feature can be useful to make a target list and the scope feature allows showing only relevant data for your testing scope.
For example; the company “Bugcrowd” that we tested and the scope is only given as “bugcrowd.com” on the scope page. In this case, you can add the relevant scope by right-clicking on a request.
You can edit this added scope value according to the given scope as follows
Finally, you should do the following filtering in the HTTP History tab by selecting “Show only in-scope items”.
These will help you to understand roles like readonly, normal, super etc in the application better.
Capture all requests!
When IDOR vulnerability testing, basically, you need to perform make all the requests that the web/mobile application should be create. Because if you changed something in the application, can create other requests using this case. If you have all API requests of the application like WSDL file, Swagger page etc. and it’s working regularly, you’re in luck! You can use this and it’ll give you convenience for IDOR testing.
An example is encountered in a private program. Credit cards are added when made the purchase in the mobile application. After the requests are tested, it can be thought that there is not any vulnerability. But when a made second purchase, credit card selection screen is seen and the IDOR vulnerability is at this point. When selecting a credit card on here, application will send the credit card id to server in a request and this request did provide to access other users’ credit cards data changing the credit card id.
In another private program, the web application included an in-app messaging system. The user could send messages to other users and add other users to own messages. When the user tries to access one of own messages, a request went to “/messages/5955” and own message id seems to be “5955”. Likewise, when trying to access another user’s message by making a request to “/messages/5955”, the message was not accessed. When the user wanted to add another user to own message, arises a request like the one below.
<span class="has-inline-color has-vivid-red-color">POST /messages/5955/invite HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0Accept: */*X-Requested-With: XMLHttpRequestCookie: my_cookiesConnection: closeuser=testaccount2</span>And when this request is examined, the user can add itself to other users’ messages and access all messages.
In addition, roles in the application must be well understood in order to identify IDOR vulnerability. If you know what that a role should do or should not do, it will be very useful during the phase of weakness detection. So firstly, you should understand the application deeply!
How to find injection points?
As before say, you can find many requests for IDOR vulnerability testing using all features of application. When API endpoints are not provided in IDOR vulnerability tests, .html source code or .js files are useful. These files include interesting things and ajax requests usually. IDOR vulnerability testing can be performed using presented requests in these files. This can be requests made earlier by the application, and possible future requests.
If you are lucky, you can see only the requests that an authorized, admin user should see in javascript files. Because of this, source code and especially javascript files should analyze well.
Also, you can search web application’s old version on “archive.org” and you may can find useful requests in old javascript files or you can search requests in search engines using dorks.
In some cases, id values aren’t unique like 1, 2, 3, 100, 1000 etc, these id values can be encoded or hashed value. If you face an encoded value, you can test the IDOR vulnerability with decoding the encoded value. If you face a hashed value, you should test whether the hash value is an accessible or predictable value. In another case, you can access hashed value in “Referrer“ header, so these scenarios can be replicated.
For example, you can’t access the another users’ objects but you can find object’s hashed id value in the object page’s source code, you can find the object’s hashed id into an in-app message from victim user (this will decrease the impact of bug). So you can create 2 test accounts as X and Y, then try to X’s hashed id value in Y’s requests in Burp History.
If we will touch another topic, some applications’ requests may scare you. For example, the SmartSheet’s request that contains more than one parameter appears to be too complex.
If you wanna find the inject point in this request, you can use Burp Suite’s compare tool. You should right-click on the request and choose “Send to Comparer” option. Then you can create the same request for using another object and send to comparer.
When you visit to the comparer tool and click on the “Words” button, you will be presented with a window where the changing points.
You can use same method for HTTP responses and you can examine their differences.
Unsuspected places to look for IDORs
Don’t ignore encoded and hashed IDs
When faced with an encoded ID, it might be possible to decode the encoded ID using common encoding schemes.
And
if the application is using a hashed/ randomized ID, see if the ID is
predictable. Sometimes applications use algorithms that produce
insufficient entropy, and as such, the IDs can actually be predicted
after careful analysis. In this case, try creating a few accounts to
analyze how these IDs are created. You might be able to find a pattern
that will allow you to predict IDs belonging to other users.
Additionally,
it might be possible to leak random or hashed IDs via another API
endpoint, on other public pages in the application (profile page of
other users, etc), or in a URL via referer.
For example, once I found an API endpoint that allows users to retrieve detailed direct messages through a hashed conversation ID. The request kinda looks like this:
<span class="has-inline-color has-vivid-red-color">GET /api_v1/messages?conversation_id=SOME_RANDOM_ID</span>This seems okay at first glance since the conversation_id is a long, random, alphanumeric sequence. But I later found that you can actually find a list of conversations for each user just by using their user ID!
Preventing IDOR Vulnerability
Your website may be vulnerable to future attacks if IDOR threat actors remain present in your web applications. Here are ways to avoid IDOR vulnerability:
Use an Indirect Reference Map
An Indirect Reference Map is an alternative design method to ‘Direct Object Reference’ that helps businesses avoid IDOR vulnerabilities. It replaces the actual references (such as user IDs, names, keys, etc.) with alternate IDs that map to the original values. The mapping between the alternate IDs and actual references are maintained safely on the servers.
Let’s go back to the credit card example. Instead of using direct references in the URL http://www.example.com/credit/profile/id#12, use indirect references http://www.example.com/c/ab. Then, refer to the indirect reference map to look for the actual reference. This way, direct references containing users’ credit card information will not be exposed.
Validate User Access
Servers fail to identify tampered URLs because there are no access checks in place at the data-object level. Data layer access controls should be enforced only when the server verifies whether the current user owns or has access permissions to the requested data.
At the very least, the application should perform a Syntactic Validation to verify suspicious inputs. The application should establish criteria for incoming input, and if it doesn’t meet expectations, reject the value.
Here are some criteria you can apply to your application:
- Minimum or maximum length
- Minimum or maximum bounds (for numeric values)
- Acceptable characters
- Data Type (e.g. string, date, integer, rational, etc.)
But what do you when an IDOR attack leads to a successful data breach?
The preventive measures mentioned above can only prevent an IDOR attack from happening, but they can’t mitigate the impact of a successful attack. Your business needs to be ready for any cyberattack situation, and that includes having an action plan post an IDOR attack.
Spanning backs up your online data and restores it in the event of a cyberattack incident, including a data breach due to IDOR vulnerability. This ensures business continuity for your web-based business even during a disaster.