One of the OWASP top 10 vulnerabilities, is IDOR which stands for Insecure Direct Object Reference. The essence of IDOR lies in an application’s inability to properly validate user input, accidentally allowing the attacker to manipulate object references and gain unauthorized access.
An occurrence of IDOR
IDOR can happen when an application provides direct access to user-supplied input. There can obviously be more than one way to do this. For example, any application hasn’t properly checked or enforced access controls when a user requests a specific object, such as a file or database record. The application uses easily guessable sequential identities to access objects, making it a lot easier for the attacker to enter the application. And lastly, when the application hasn’t been properly validated. There are some cases of session management as well, where poor management can also lead to hackers impersonating other users.
Let’s understand with a basic test case:
“You log in to your xyz.com account and navigate to your profile, which contains your phone number, email address, and other PII information. The API request is GET /user/123, where 123 is your user ID, which should be linked to the session/authorization token.
However, this is not the case.
So, if you replace the user ID with another user’s ID, their PII information will be shown in the answer.
The fix for this will be to validate that user ID or any object ID that is vulnerable to IDOR, should be mapped with or belong to the logged-in user.
Some common scenarios where IDOR can occur:
- Account Access: Many systems allow users to access and manage multiple accounts. These can be anything from emails to bank accounts. If the user privileges for these are not checked properly, the account references can be manipulated by the attacker.
- Downloading files: There are numerous websites that serve files, that can be used quite predictable URLs or filenames. Lack of access control here can lead the attacker to sensitive data.
- Database Manipulation: Easily guessable record IDs in the database management can be altered or deleted if not validated.
Some methods to identify IDOR vulnerabilities:
- Path traversal: This type of IDOR vulnerability allows an attacker to access or manipulate files or folders directly on the server, running on the application.
- JSON ID Manipulation: JavaScript Object Notation (JSON) is frequently used behind the scenes to store and communicate data between client and server, aiding in the dynamic nature of online sites.
Now since we have the idea of how an IDOR can take place. We’ll move forward with some strategies to help us mitigate them.
- Implementing strong access control mechanisms to ensure that users can only access resources they are authorized to.
- Using unique and random identifiers over easily guessable ones makes it difficult for the attackers to guess.
- To ensure that the user input on the server side isn’t malicious, validate and sanitize it.
- Security testing at regular intervals, involving code reviews and penetration testing, to remediate the identified vulnerabilities.
- Ensuring error handling messages don’t reveal any sensitive information
- Employing Web Application Firewalls, providing an extra layer of security, by filtering and blocking malicious requests.
We have covered enough preventions to be able to avoid IDOR vulnerabilities. As security is a continuous process, following the best possible practices can help control the damage that can occur.
Visit AppSecure Security to learn more about vulnerabilities and their countermeasures.
