Insecure Direct Object Reference

Definition:

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.

For example, in Internet Banking applications, it is common to use the account number as the primary key. Therefore, it is tempting to use the account number directly in the web interface. Even if the developers have used parameterized SQL queries to prevent SQL injection, if there is no extra check that the user is the account holder and authorized to see the account, an attacker tampering with the account number parameter can see or change all accounts.

Protection:

The best protection is to avoid exposing direct object references to users by using an index, indirect reference map, or other indirect method that is easy to validate. If a direct object reference must be used, ensure that the user is authorized before using it.

Establishing a standard way of referring to application objects is important:

• Avoid exposing private object references to users whenever possible, such as primary keys or filenames.

• Validate any private object references extensively with an "accept known good" approach.

• Verify authorization to all referenced objects.

• Make sure that input does not contain attack patterns like ../ or

If you must expose direct references to database structures, ensure that SQL statements and other database access methods only allow authorized records to be shown:

Another solution is to check the integrity of parameters to verify that parameters are not changed. This integrity check can be added as an additional parameter using encryption or hashing techniques. We can add salt to the parameter and hash the total than check it before using so it can not work if changed.

.Net Overview:
We use Tamper-Proof Link generation methods. We do not allow users to change querystrings. If they change query strings some value they get an error page.

For more information read this articles
http://aspnet.4guysfromrolla.com/articles/083105-1.aspx
http://msdn.microsoft.com/en-us/magazine/cc163462.aspx