Insecure Direct Object References Closing the doors

Mar 04, 2015 Vivek Sharma

We have all worked on scenarios where we grant system object access to certain users based on the parameter, provided by them. Sometimes, the user just changes the parameter passed as input intelligently, and she gets access to some restricted documents or db data.

For example, you should not be able to see your manager’s review document unless approved by him, or an executive should not have knowledge of some company documents, such as company’s performance report for a quarter, that senior management has access to.

Security Business Case

Consider a system’s valid user who has an account ‘myaccount’ in the system.  The below query executes and gives him access to data intended for him.

http://businessite.com/doc/accountInfo?acct=myaccount

String query = “SELECT * FROM accts WHERE account = ?”;

PreparedStatement pstmt = connection.prepareStatement(query , … );

pstmt.setString( 1, request.getParameter(“myaccount “));

ResultSet results = pstmt.executeQuery( );

Now, the user just passes another intelligently guessed parameter ‘intelliacnt’

http://businessite.com/doc/accountInfo?acct=someaccount

This parameter will sit in the above query and may give user the access to some restricted data.

The crux of the above example is that the data is protected using presentation layer logic.  Once the client is removed, all system objects are at stake.

 

Safety Measures

  • The primary check to fix Insecure Direct Object Reference Vulnerability is to have relevant access control at object reference level, be it a database or a set of files. Developers should test the scenario of accessing a restricted object reference by a non-user of that object. If the object reference is linked indirectly to a non-user, this too should be tested.

It is recommended to use ESAPI. ESAPI provides an interface AccessController, that provides methods meant to enforce access control on URLs, business functions, data, services, and files. The implementation of this interface requires access to the current User object (from Authenticator.getCurrentUser()) to determine roles or permissions. The intent of ESAPI access control interface is to centralize access control logic, so that access control is easy to use and verify.

An example to use the access controller to verify access control is given below.

try {

ESAPI.accessController().assertAuthorized(“businessFunction”, runtimeData);

// execute BUSINESS_FUNCTION

} catch (AccessControlException ace) {

… attack in progress

}

 

  • It is recommended to use indirect temporary references for each direct object reference. ESAPI provides an interface AccessReferencMap that is used to map internal direct object references to corresponding indirect references that are safe to disclose publicly. This interface help protect db keys, filenames, and other references.

An example to get the indirect reference is given below.

       Set fileSet = new HashSet();

fileSet.addAll(…); // add direct references (e.g. File objects)

AccessReferenceMap map = new AccessReferenceMap( fileSet );

// store the map somewhere safe – like the session!

String indRef = map.getIndirectReference( file1 );

 

Next up, I would be looking at the Cross Site Request Forgery as a security concern.


Fixed Price Security Assessment offer

As part the Fixed Price Security Assessment offer, we run the security assessment tools to identify the vulnerabilities and the assessment reports are aggregated, analyzed and a final report will be generated. We need a minimum information about the application and access. If this is an area of interest, we’d love to spend about 20 minutes discussing your product and current needs. Based on our discussions, we will also offer a one day free security evaluation of your software….

Vivek Sharma

Over 10 years of experience in technology and extremely interested in software security. Experienced in working with banks to safeguard against security threats. He spends his free time deep in stock market analysis.