IDOR
EXPLOITATION
IDOR, short for Insecure Direct Object Reference is a type of vulnerability where an application gives the user too much power to access information stored in the backend by making storage access identifiers or patterns visible in a way that would allow an attacker to change these parameters and access accounts, pages, and information that they should not be able to access.
A good brief example would be if the URL to access a page had the employee ID# somewhere in the field. This could allow an attacker to change the employee ID and thus gain access in this way to pages belonging to other employees.
OWASP has even put together a cheat sheet to help prevent common IDOR vulnerabilities.
WHERE TO LOOK FOR IDORs
A common location for IDOR vulnerability would be in the address bar of a website. Many times, specific identifiers can be found in the address bar to specify certain accounts, pages, or values.
Not all vulnerable endpoints are contained in URLs, however. Some are more hidden and may require a look at an AJAX request or a JavaScript file to see referenced values.
A good way to scan for potential IDOR vulnerabilities is to capture requests being made and received from the webserver. Some requests may contain IDs or other values that could be modified to access different information.
ENCODED/HASHED VALUES
It's always good to keep in mind that not all data is displayed or sent in human-readable text, this can be the case for IDOR vulnerabilities as well.
Two common ways of having data changed is to encode or hash it.
Base32 and base64 are common encoding formats. You can easily decode and encode values using online tools that can encode and decode base32 and base64 values to decode an encoded value into something that can be read and modified.
You can also use those same tools to encode the modified cookie values back to an encoded string before sending the tampered request.
A hashed ID is more difficult to crack, since, unlike encoding, hashing is a security feature that would require extra tools or knowledge of hash values to convert back to its un-hashed format.
Since IDOR vulnerabilities usually follow some sort of pattern or format, it's possible to iterate through a suspected range of different ID values by hashing potential values until finding a matching hash.
An easier way to crack a hash would be to use a tool such as CrackStation by entering the hash and seeing if the massive indexed pre-computed tables in the site's database have a cracked value for that hash.
TWO ACCOUNT CHECK
A good method to detect potential IDORs is to create two accounts on a web server and swap the ID numbers between them to see if you can access the second account while being logged in with the first, or while not being logged in at all.
If so, then you have discovered an IDOR vulnerability since the system allowed for account access without verifying if the correct user is trying to access the account.
DEVELOPER TOOLS
Using the network tab in a browser's developer tools is a great way to isolate requests that could contain IDs linked to certain page or form values. By accessing these isolated requests, it's possible to manipulate these values that may otherwise be hidden.