Found IDOR? Can you enumerate identifiers (references)?
Today I am jotting down my observation for one of the most prevalent vulnerabilities in application security testing — Insecure Direct Object Reference (IDOR); and potentially how we can reduce the likelihood and thus severity of it.
So what is IDOR
As per OWASP documentation, Insecure Direct Object Reference (called IDOR from here) occurs when an application exposes a reference to an internal implementation object. Using this way, it reveals the real identifier and format/pattern used of the element in the storage backend side.
Simply put, when an application is providing unauthorised (insecure) access to an object directly by an identifier (reference). This identifier can be a string, integer, encoded value etc. For e.g. if an endpoint https://example.com/get_sensitive_information.php?user_id=[user_id] returns the sensitive information about the user object and doesn’t validate whether logged-in user is “authorised” to access the requested user_id identifier, then endpoint is vulnerable to IDOR.
Severity analysis of IDOR
Like most vulnerabilities, severity of IDOR majorly depends on two parameters — likelihood and impact.
Impact of IDOR directly depends on sensitivity and criticality of information it returns, which in most-cases is the requirement of business and cannot be controlled.
One of the factors which drives Likelihood for IDOR is ability to enumerate the identifiers (references). Easy enumeration leads to higher likelihood and thus increasing the severity.
Thoughts on identifier enumeration
So if, by design, we define the identifier of objects as difficult-to-brute-force in application, then that will reduce the likelihood and thus severity of IDOR vulnerabilities significantly.
So in example https://example.com/get_sensitive_information.php?user_id=[user_id], consider scenarios where endpoint is vulnerable to IDOR but,
- user_id is a 8 digit number (549736852)
- user_id is a UUIDv4 (5305b86d-9d5b-4a52-a19e-9434967ab282)
I am sure all of us will agree that severity in the second case will be significantly less than in the first case.
By no means, I am proposing it as a solution for IDOR. Proper authorization matrix and access control is the ideal solution for IDOR, but adopting the above approach on organisation level will help make it less severe, consistently.
Possible candidates for using difficult to brute-force can be UUIDv4, hashes, reasonably long random strings etc. From development efforts perspective access controls need to be implemented on all CRUD operations, while identifier definition happens on (C)reation operation only, thus relatively less effort to implement.
