According to the 7th Annual Hacker-Powered Security Report, IDOR makes up 7% of the vulnerabilities reported via the HackerOne platform. Government agencies and automotive organizations saw particularly high incidences of IDOR reports, making up 15% of reports to government agencies and 11% of reports in the automotive sector.
IDOR vulnerabilities can arise in a variety of components, including:
URL Query Parameters
Resources that are associated with query parameters in a URL address can be easily modified by end-users. For example:
| https://example.com/account?id=3 |
By simply changing the numerical value of the id parameter that specifies which user account is displayed, a user could access the accounts of any other user as long as the supplied number was associated with an account. It occurs due to missing access control checks that fail to validate user permissions. In the absence of rate limiting implementation, automated tooling could iterate through a massive quantity of potential numerical values in a short amount of time.
Filenames can also be a possible attack vector for IDOR vulnerability exploitation. They can either be referenced directly for files within the same directory or with the use of directory traversal techniques (or simply supplying the absolute path), the entire file system can be exposed.
HTTP Requests
Hypertext Transport Protocol (HTTP) requests contain multiple different elements that could lead to IDOR exploitation, such as:
Headers: Request headers, such as Cookies serve as user identifiers in order to serve user specific resources. If the values lack sufficient entropy, valid values can be easily guessed. To illustrate, the following example uses a sessionid cookie with a length of only six characters. If every sessionid adheres to the same format of three lowercase letters with numbers populating the last three indices, the total number of possible unique combinations is 17,576,000. Again, without the protections offered by rate limiting, massive quantities of requests could be sent using automated tooling to enumerate active user sessions, leading to account takeover.
| GET /uploads HTTP/1.1 Host: example.com Cookie: sessionid=abc123 |
Body Data: Body data, in its multiple types can contain vulnerable parameters. For instance, the following form submission request to change the associated email address to an account could be exploited by malicious attackers to gain control over a victim account:
| POST /change-account-email HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 44 username=johndoe&email=johndoe%40example.com |
JSON data sent in API requests can also be a vulnerability source:
| POST /api/v2/user-data HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 64 { |
HTTP Responses
Responses can also include vulnerable headers and body data. For example, consider a web application using feature flags in order to display different elements of the user interface depending on the user’s role. Utilizing match-and-replace rules could facilitate IDOR vulnerabilities. The HTML file served in the response could contain a parameter similar to the following:
Setting the value of isAdmin to true may enable portions of the user interface that are only intended for legitimate website administrators.
The Exploit
On September 27th 2022, security researcher reachaxis submitted a report describing an IDOR vulnerability they discovered on https://mtnmobad.mtnbusiness.com.ng/. Due to a lack of authorization verification, remote users were able to alter the account information of any other user.
The information that was able to be changed included the username, company name, address, company size, and critically the mobile phone number of the associated account.
As this web application provided accounts for advertising partners, an attacker could have negatively impersonated the affected company using the supplied phone number. Due to this, the finding was rated as Critical in severity.
Steps to Reproduce
1. Two accounts were created: one representative of the victim and the other assuming the role of an attacker.
2. Both accounts were logged into using separate browsers to avoid session conflict issues.
3. In the response to the POST request made to the /app/dashboardData endpoint, the account id and email associated with other accounts could be obtained.
4. The form used to update account information was located at https://mtnmobad.mtnbusiness.com.ng/#/UserProfile. Submitting the form generated a request to the /app/updateUser endpoint.
5. By submitting the form in the attacker’s session and intercepting the subsequent request to /app/updateUser using an HTTP proxy tool, the request could be modified.
| POST /app/updateUser HTTP/1.1 Host: mtnmobad.mtnbusiness.com.ng –snip– “updates”:[ { “param”:”user”, “value”:{ “id”:”/333″, “contact”:{ “name”:”ABC”, “address”:”ABC” “mobile”:”0000000123″ “email”:”attacker@example.com” }, “companyName”:”ABC”, “companySize”:”<50" }, “op”:”a” } ], –snip– |
6. By replacing the account ID and email to match the victim’s, the username, company name, address, company size, and mobile phone number associated with the victim’s account could be changed to arbitrary values.
| HTTP/1.1 200 OK Server: nginx/1.4.6 (Ubuntu) –snip– { |
Protecting Against IDOR Attacks
As IDOR vulnerabilities are considered to be a subset of access control vulnerabilities, the implementation of proper authorization mechanisms could have prevented this vulnerability.
The disclosure of sensitive data, such as the account identifier and email address of other accounts, to all users was key in exploiting this vulnerability. Without knowing the email address associated with the victim’s account, an adversary would have had a much more difficult time exploiting this vulnerability.
On the other hand, had the attacker only known the email address of the victim’s account, it is worth noting that the account identifier was only three digits in length, meaning there were only 1,000 possible unique combinations. If an attacker supplied a valid email address, by utilizing automated tooling, the matching account identifier could have been discovered in a very short amount of time.
To remediate IDOR vulnerabilities that arise in a similar nature, the following best practices should be adhered to:
- Automated tooling should not be relied upon solely to identify possible IDOR vulnerabilities. Manual review is the best method to identify areas of your application that can be a source of these issues as a deep understanding of the underlying logic of your application is required.
- Developers should avoid publicly displaying references to objects, as in this case, it only required the enumeration of two objects (the target id and email) in order to carry out an attack.
- Any references to resources should be cryptographically strong random values rather than short-length numerical, possibly sequential, values. These obfuscated values can then be mapped back to their original reference so the application can match the two. Note that this is considered a defense-in-depth measure and should not be relied upon solely.
- In order to counter automated tooling, rate limit protections can be integrated to ensure requests are processed at a rate realistic to normal user activity levels.
- Enforce authorization checks to verify that the correct users only access resources intended for them. By correlating the appropriate resources to a user’s session, unauthorized access to additional resources can be mitigated. There are web frameworks that often provide ways to facilitate this.
Conclusion
The presence of IDOR vulnerabilities can lead to severe consequences for an organization and its users. By adhering to security best practices, the risk of falling victim to an attack of this type can be greatly reduced. By understanding how they occur and how they are exploited, you and your team will be able to identify potential conditions that would result in an IDOR vulnerability.