Authorization concerns the actions that users are permitted to do. While users might successfully authenticate to a system with their username and password, they may not be allowed to access certain resources, change or delete data, or change system settings. Only users with appropriate authorization are allowed to do these things.
HTTP parameter pollution (HPP) vulnerabilities can be introduced if multiple HTTP parameters have the same name. This issue may cause an application to interpret values incorrectly. An attacker may take advantage of HPP vulnerabilities to bypass input validation, trigger application errors, or modify internal variable values.
>NOTE HPP vulnerabilities can lead to server- and client-side attacks.
An attacker can find HPP vulnerabilities by finding forms or actions that allow user-supplied input. Then the attacker can append the same parameter to the GET or POST data – but with a different value assigned.
Consider the following URL:https://store.h4cker.org/?search=carsThis URL has the query string **search** and the parameter value **cars**. The parameter might be hidden among several other parameters. An attacker could leave the current parameter in place and append a duplicate, as shown here:https://store.h4cker.org/?search=cars&results=20The attacker could then append the same parameter with a different value and submit the new request:https://store.h4cker.org/?search=cars&results=20&search=bikesAfter submitting the request, the attacker could analyze the response page to identify whether any of the values entered were parsed by the application. Sometimes it is necessary to send three HTTP requests for each HTTP parameter. If the response from the third parameter is different from the first one – and the response from the third parameter is also different from the second one – this may be an indicator of an impedance mismatch that could be abused to trigger HPP vulnerabilities.
Occurs when an application exposes internal object identifiers, like database keys or file paths, to users without proper access controls. This can happen when user input, like an account number, is directly linked to an application’s object without any checking mechanism to stop unauthorized users from accessing it.
Insecure Direct Object Reference vulnerabilities can be exploited when web applications allow direct access to objects based on user input. Successful exploitation could allow attackers to bypass authorization and access resources that should be protected by the system (for example, database records, system files). This type of vulnerability occurs when an application does not sanitize user input and does not perform appropriate authorization checks.
IDOR comes under Broken Access Control ↗ in OWASP top10 2021 where it ranked #1 in terms of web application security risk.
An attacker can take advantage of Insecure Direct Object References vulnerabilities by modifying the value of a parameter used to directly point to an object. In order to exploit this type of vulnerability, an attacker needs to map out all locations in the application where user input is used to reference objects directly.
Sometimes application use UUID’s instead of numeric id’s. UUID’s are unpredictable long strings. They look like this: bfe5c6a8-9afa-11ea-bb37-0242ac130002. They don’t protect against IDOR’s but they do make it harder to exploit. Sometimes applications leak the UUID, on purpose or by accident. For example, when you visit another user’s profile, they may have a profile photo that’s stored on the website in a folder the same as their UUID: <img src="/assets/profile_picture/bfe5c6a8-9afa-11ea-bb37-0242ac130002/avatar.png">
Mitigations for this type of vulnerability include input validation, the use of per-user or session Indirect Object References, and access control checks to make sure the user is authorized for the requested object.