Difference between revisions of "Top 10 2013-A4-Insecure Direct Object References"

From OWASP
Jump to: navigation, search
m (brighter background for 'Top_10_2010:ExampleBeginTemplate' => added '|year=2013')
(added 'Ax-' in |next= and prev= in BottomTemplate)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
 
     |usenext=2013NextLink
 
     |usenext=2013NextLink
     |next={{Top_10_2010:ByTheNumbers
+
     |next=A5-{{Top_10_2010:ByTheNumbers
 
               |5
 
               |5
 
               |year=2013
 
               |year=2013
 
               |language=en}}
 
               |language=en}}
 
     |useprev=2013PrevLink
 
     |useprev=2013PrevLink
     |prev={{Top_10_2010:ByTheNumbers
+
     |prev=A3-{{Top_10_2010:ByTheNumbers
 
               |3
 
               |3
 
               |year=2013
 
               |year=2013
 
               |language=en}}
 
               |language=en}}
 +
    |year=2013
 +
    |language=en
 
}}
 
}}
  
Line 15: Line 17:
 
   {{Top_10:SummaryTableTemplate|exploitability=1|prevalence=2|detectability=1|impact=2|year=2013|language=en}}
 
   {{Top_10:SummaryTableTemplate|exploitability=1|prevalence=2|detectability=1|impact=2|year=2013|language=en}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013}}
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the types of users of your system. Do any users have only partial access to certain types of system data?
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
.</td>
+
Consider the types of users of your system. Do any users have only partial access to certain types of system data?
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted?
+
 
 
</td>
 
</td>
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is properly verified.
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
 +
Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted?
 +
 
 
</td>
 
</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Such flaws can compromise all the data that can be referenced by the parameter. Unless the name space is sparse, it’s easy for an attacker to access all available data of that type.
+
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
 +
Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.
 +
 
 +
</td>
 +
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
 +
Such flaws can compromise all the data that can be referenced by the parameter. Unless object references are unpredictable, it’s easy for an attacker to access all available data of that type.
 +
 
 
</td>
 
</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the exposed data.
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the exposed data.
  
Also consider the business impact of public exposure of the vulnerability.
+
Also consider the business impact of public exposure of the vulnerability
 
</td>
 
</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
  
 
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=4|year=2013|language=en}}
 
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=4|year=2013|language=en}}
The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:
+
The best way to find out if an application is vulnerable to insecure direct object references is to verify that <u>all</u> object references have appropriate defenses. To achieve this, consider:
# For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
+
# For '''direct''' references to '''restricted''' resources, does the application fail to verify the user is authorized to access the exact resource they have requested?
# If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.
+
# If the reference is an '''indirect''' reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?
  
 
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
 
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
 +
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=4|year=2013|language=en}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=4|year=2013|language=en}}
 
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
 
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
 +
# '''Use per user or session indirect object references.''' This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s [https://www.owasp.org/index.php/ESAPI ESAPI] includes both sequential and random access reference maps that developers can use to eliminate direct object references.
 +
# '''Check access.''' Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
  
# Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s [https://www.owasp.org/index.php/ESAPI  ESAPI] includes both sequential and random access reference maps that developers can use to eliminate direct object references.
 
# Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
 
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=4|year=2013|language=en}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=4|year=2013|language=en}}
 
The application uses unverified data in a SQL call that is accessing account information:
 
The application uses unverified data in a SQL call that is accessing account information:
{{Top_10_2010:ExampleBeginTemplate|year=2013}}<nowiki>
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 
String query = "SELECT * FROM accts WHERE account = ?";
 
String query = "SELECT * FROM accts WHERE account = ?";
 +
 
PreparedStatement pstmt = connection.prepareStatement(query , … );
 
PreparedStatement pstmt = connection.prepareStatement(query , … );
  
{{red|pstmt.setString( 1, request.getParameter("acct"));}}
+
<span style="color:red;">pstmt.setString( 1, request.getParameter("acct"));</span>
  
 
ResultSet results = pstmt.executeQuery( );
 
ResultSet results = pstmt.executeQuery( );
</nowiki>{{Top_10_2010:ExampleEndTemplate}}
+
{{Top_10_2010:ExampleEndTemplate}}
  
 
The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account.
 
The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account.
Line 58: Line 70:
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 
* [https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference  OWASP Top 10-2007 on Insecure Dir Object References]
 
* [https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference  OWASP Top 10-2007 on Insecure Dir Object References]
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.html  ESAPI Access Reference Map ]API
+
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.html  ESAPI Access Reference Map API]
 
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html  ESAPI Access Control API] (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )
 
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html  ESAPI Access Control API] (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )
  
Line 65: Line 77:
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
 
* [http://cwe.mitre.org/data/definitions/639.html  CWE Entry 639 on Insecure Direct Object References]
 
* [http://cwe.mitre.org/data/definitions/639.html  CWE Entry 639 on Insecure Direct Object References]
* [http://cwe.mitre.org/data/definitions/22.html  CWE Entry 22 on Path Traversal] (which is an example of a Direct Object Reference attack)
+
* [http://cwe.mitre.org/data/definitions/22.html  CWE Entry 22 on Path Traversal] (is an example of a Direct Object Reference attack)
  
 
{{Top_10_2013:BottomAdvancedTemplate
 
{{Top_10_2013:BottomAdvancedTemplate
 
     |type={{Top_10_2010:StyleTemplate}}
 
     |type={{Top_10_2010:StyleTemplate}}
 
     |usenext=2013NextLink
 
     |usenext=2013NextLink
     |next={{Top_10_2010:ByTheNumbers
+
     |next=A5-{{Top_10_2010:ByTheNumbers
 
               |5
 
               |5
 
               |year=2013
 
               |year=2013
 
               |language=en}}
 
               |language=en}}
 
     |useprev=2013PrevLink
 
     |useprev=2013PrevLink
     |prev={{Top_10_2010:ByTheNumbers
+
     |prev=A3-{{Top_10_2010:ByTheNumbers
 
               |3
 
               |3
 
               |year=2013
 
               |year=2013
 
               |language=en}}
 
               |language=en}}
 +
    |year=2013
 +
    |language=en
 
}}
 
}}
  
 
[[Category:OWASP Top Ten Project]]
 
[[Category:OWASP Top Ten Project]]

Latest revision as of 17:19, 14 June 2013

← A3-Cross-Site Scripting (XSS)
2013 Table of Contents

2013 Top 10 List

A5-Security Misconfiguration →
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
EASY
Prevalence
COMMON
Detectability
EASY
Impact
MODERATE
Application / Business Specific

Consider the types of users of your system. Do any users have only partial access to certain types of system data?

Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted?

Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.

Such flaws can compromise all the data that can be referenced by the parameter. Unless object references are unpredictable, it’s easy for an attacker to access all available data of that type.

Consider the business value of the exposed data.

Also consider the business impact of public exposure of the vulnerability

Am I Vulnerable To 'Insecure Direct Object References'?

The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:

  1. For direct references to restricted resources, does the application fail to verify the user is authorized to access the exact resource they have requested?
  2. If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?

Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.

How Do I Prevent 'Insecure Direct Object References'?

Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):

  1. Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
  2. Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
Example Attack Scenarios

The application uses unverified data in a SQL call that is accessing account information:

String query = "SELECT * FROM accts WHERE account = ?";

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

pstmt.setString( 1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account.

http://example.com/app/accountInfo?acct=notmyacct

References

OWASP

For additional access control requirements, see the ASVS requirements area for Access Control (V4).

External

← A3-Cross-Site Scripting (XSS)
2013 Table of Contents

2013 Top 10 List

A5-Security Misconfiguration →

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png