When it comes to web application security, we often focus on the more "technical" vulnerabilities. Things like XSS, CSRF, SSRF, Serialization attacks, RCE, etc. However, more often than not, there are a multitude of vulnerabilities hiding in the business logic layer. An excellent example of this is Insecure Direct Object Reference (IDOR) attacks.
IDOR is a fancy name for a simple concept in web application security. Imagine the following endpoint in a web application.
/push.php?name=friendly_name&id=42496This example demonstrates a simple API endpoint that takes two GET parameters, "name" and "id". The concern here is the "id" exposed to the user. What would happen if we could changed this value? Could we submit data under a different id? Could we retrieve data? The threat of IDOR comes when the application does not properly check that the current user has the authority to modify that object.
How do we prevent this type of attack? Your first thought may be to use a UUID. UUIDs make it difficult to guess values (if the variable is 100, an attacker may try similar values; 99, 101, 102, etc.) and serve as an excellent abstraction from the actual object. The key issue here is that an attacker may attempt to leak this value through other attack vectors in your application.
While it may be a good idea to use some kind of abstractive value, the real solution is to validate that the current session has the access to make the request submitted. This way even if an attacker guesses another user's object reference, steals the abstracted value, or even steals the real one, their malicious request will not be processed.
When performing a penetration test or an application security assessment of a web application, IDOR attacks will often reveal themselves when using a proxy (like Burp Suite). If you notice a parameter that may be used to reference or control a query, you should test to ensure it cannot be used in an IDOR attack.