OWASP Top Ten Project 2013 No 4 – Insecure Direct Object References

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).

Access Check

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)

Example

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 GetBasketByID pipelet:

[code language=”java”] …
Basket basket = basketMgr.resolveBasketFromID(basketID);
if (basket == null)
{
return PIPELET_NEXT;
}
//only baskets from current user are allowed
if (currentUserOnly && !basket.getUser().equals(user))
{
pipelineDictionary.put("ERROR_User", "true");
return PIPELET_ERROR;
}
…
[/code]

Co-Authors: Thomas Bergmann, Nils Breitmann and Intershop Consulting Stuttgart