Indirect Object References
Sensitive parameters in URLs should be encrypted or processed in a way that the range of possible values is much larger than the range of really used values. The probability to guess a valid value would drop considerably. An example is the usage of product UUIDs instead of product SKUs (stock keeping units).
Ideally the access to (sensitive) data is done at the lowest, the object level, instead of securing only (certain) paths to an object.
The Intershop pipeline request processing allows ACL permission check. A user needs in a specific context (organization/channel) permission for the executed action. In case of an indirect object access the implementation needs to be aware of resolved objects of another context.
- Resolving UUID from request (verify the domainid of the returned object)
- Search results (add domainid as additional query parameter)
- 1 to n relation (returned objects could be from other contexts, sometimes)
For example an URL might exist that displays the basket of the current user, e.g., https://127.0.0.1/INTERSHOP/web/WFS/PrimeTech-PrimeTechSpecials-Site/en_US/-/USD/ViewCart-View?BasketID=12345. Somebody might try to change the value of the
BasketID parameter to display the basket of somebody else. So it is necessary to check whether the basket can be accessed with the current context (here by the current user) as it is done at the
Basket basket = basketMgr.resolveBasketFromID(basketID);
if (basket == null)
//only baskets from current user are allowed
if (currentUserOnly && !basket.getUser().equals(user))
Co-Authors: Thomas Bergmann, Nils Breitmann and Intershop Consulting Stuttgart
2 thoughts on “OWASP Top Ten Project 2013 No 4 – Insecure Direct Object References”
WordPress takes code blocks into muddle. Check for the double ampersand in your code example. Great article, btw…
Thanks for spotting!
Comments are closed.