An application’s architecture is both an outcome and a process. As an outcome, it describes an application’s ability to perform the assigned tasks; as a process, the architecture is a set of practices guided by the principles that produce the outcome.
Web and Mobile applications are very alluring to organizations, providing quick, user-friendly interfaces and effortless deployment to remote users. Ironically, the same reasons render them a security risk. Unauthorized application users too, can avail the same benefits: Quick, User-friendly and Effortless access to data.
I would like to share an interesting finding that our team came across on a popular cloud platform. The platform is a multi-device; with browser based, OS and mobile clients. Amongst various observations, the finding that left us amazed was an Insecure Direct Object Reference (IDOR) or a Vertical Privilege Escalation vulnerability which allows a user to gain access to more resources or functionality than ideally allowed.
Without getting into the specifics of the platform (owing to client confidentiality) let’s just say that an IDOR in this case was huge since the platform’s biggest selling point was its RBAC (Role Based Access Control). Things become more interesting (read worse) especially in case of multi-tenant deployments.
Typical RBAC based applications have the following user roles
;1. Super Admin
2. Administrator
3. User
Super-Admins are System-Wide administrators with a maximum number of privileges. Administrators are in- charge of a particular enterprise or group. The user is a low-privilege user who has standard functionality within the context of an enterprise account.
Multi Layered / Stacked applications are extensively driven using REST APIs with JSON as a primary payload for performing popular CRUD operations.
The bug in this case was identified in the User Profile update workflow. The User’s profile was modified by the Administrator and prior to updating the modified record, the request was intercepted using a proxy. Amongst other parameters in the JSON array was a parameter called “Role” which was tampered with numerical values that we believe mapped out to a specific set of roles in the application.
For instance, the RoleID: 3 would be for an Administrator, but a RoleID: 4 may be for a super-administrator. Upon forwarding the tampered request, the user profile was updated successfully and voila! - "User" was now "Super Admin". This exploit is a conjunction of Insecure Direct Object Reference and Vertical - Privilege Escalation where a lower privilege user accesses functions or content reserved for higher privilege users or applications.
Now – finding an issue is just half the equation. The actual value that security engineers need to provide are- Feasible and implementable solutions to such attacks.
In my honest opinion, the ideal protection against an IDOR attack is to avoid exposing direct object references to users by using an Index, an Indirect Reference Map, or any other indirect method of validation. If a direct object reference is unavoidable, ensure that the user is authorized before using it. Also useful would be to:
