Insecure Direct Object Reference (IDOR) – A Gaping Hole

Insecure Direct Object Reference (IDOR) – A Gaping Hole This is an aerial shot of sheep leaving a grazing field in complete accord through a narrow gate while it looks like there isn’t even a fence in the first place (or perhaps a frail one that would not hold for long). The sheep are conditioned to think that the narrow gate is their only way out and each of them can only leave the field by passing through it.

This is a fascinating phenomenon that goes to show how easily the individual can be trained to fall in with the herd.

Now if you were to assume that the users of your application, like these sheep, will always follow rules, things can go very wrong. It would be no overstatement to say that this assumption is the root cause of most errors in the ‘authentication-authorization-session management’ triad of web and mobile applications everywhere. Particularly, in the case of the highly potent but often overlooked IDOR vulnerability. Given the chance, a snoopy user can be expected to ‘explore’ and poke around for hidden treasures.

Insecure Direct Object References occur when the reference to an internal object is exposed without proper access control checks in a way that would allow a malicious user to access restricted objects. Commonly exploited by even amateur hackers, the IDOR flaw can be leveraged to access, modify or destroy database and file entries, widely impacting the privacy and availability of application data and user data. The vulnerability stems from improper input validation with the intent to administer access control i.e. to verify that the user requesting access to an object is permitted to view it.

“Anticipating deviation is essential in forestalling unauthorized access.

Assume that all input has potential to be malicious.”

Examples and Instances of IDOR The IDOR vulnerability is commonly used in Directory Traversal attacks where a user attempts to identify the architecture of directories through the structure of the URL for his own allowed pages on the application.

Using this knowledge he then tries to navigate the file system and access other resources he may not be permitted to view. Say, an online software tutorial website has a directory of lessons under different programming languages. When a user registered for Java courses sees a simple file path in his URL with straightforward identifiers, he may try to play around a bit in an attempt to get his hands on other courses he has not paid for.

In a similar scenario, an IDOR flaw was found on a web application that hosts live-streaming art lessons. The flaw allowed any authenticated user to access the playlists, schedulers and menu items of other registered users of the app. Manipulation of functions like ‘Update Details’ gave him the ability to change passwords as well as recovery email IDs and thereby steal multiple accounts. All it took was a change in the user ID in a POST request sent to access the target page.

If the same flaw were to be milked in the context of an ecommerce application to circumvent business logic, the damages would be farreaching. An online retailer giant’s web application which had a proprietary wallet feature contained an Insecure Referencing flaw that made it possible to access the wallets of other valid users.

The error is quite simple which explains why developers often fail to notice it.

The application would fetch wallet details to a request that only carried the ‘userid’ parameter while it should have required the ‘random-session-id’ as the primary key for the object. By simply randomizing the user ID value, a threat actor could have easily stolen wallet funds of multiple users to use on his own purchases.

Keep these in mind 1. An unambiguous file structure with explicit and plainly obvious identifiers and labels make for a ‘tactless’ defense.

2. Can users gain direct access to file resources by manipulating object IDs? Verify this through manual code reviews and consider mapping original IDs to complex GUIDs that can then be exposed to users safely since it guarantees that the mapped resources are available only for the current user in his/her current session.

3. To prevent traversal, implement inbuilt controls to validate and sanitize inputs. Rigorous input validation not only protects from IDOR-related exploits but XSS and other injection attacks too.

Enumerate all probable Input Vectors wherever the application renders database items to a user which may include HTML forms and file uploads. In POST and GET requests, query parameters could let an attacker obtain file system privileges (dot-dot-slash attack). Invest time in boundary testing.

Application Security, Authentication and Authorization, Fixing IDOR, IDOR Vulnerability, Input Validation, Insecure Direct Object Reference, Mobile Application Risks, OWASP, Vulnerability Assessment and Penetration Testing, Web Application Security, Network Security, MSSP, Ethical Hacking, Managed Security Services