A4-Insecure Direct Object References

Insecure Direct Object References prevalence are quiet common and this risk can be easily exploited, anyway the impact of risk would be moderate.

Here is the sample scenario, we are having a attacker, webserver and a Database.Here what the attacker to do is simply changing the ID in the URL, now the website saves the request and it goes to database and fetch different record than the permitted for the user. If the Insecure Direct Object References is successful then the database passes request to the website and data provided to the attacker.

UNDERSTANDING DIRECT OBJECT REFERENCES 

In this example an legitimate user asking for account balance, so hitting a balance resource and a query string(ID=) , now take the other user’s they are hitting the same URL and the only difference is the account ID.

- Advertisement -

Here is the thing about these URL’s ID=(this is untrusted data),this query string value has been easily manipulated that any one of the user can change the account ID and fetch the balance of other users.In the system we need to implement validation, if the users manipulates the request,they will not be permitted to unauthorized area.

COMMON DEFENSES 

• Implement access controls, be explicit about who can access the resources.
• Use Indirect reference map, Don’t expose internal key’s externally.
• If possible map them to the temporary one’s.
• Avoid predictable keys, (Incrementing integers and Natural keys are discoverable).