This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Top 10-2017 A5-Broken Access Control"

From OWASP
Jump to: navigation, search
(Create an empty page for the new/reactivated Top 10 2017-A4-Broken Access Control (RC1))
 
Line 1: Line 1:
−
{{Top_10_2013:TopTemplate
+
'''Bold text''''''Bold text'''{{Top_10_2013:TopTemplate
 
     |usenext=2013NextLink
 
     |usenext=2013NextLink
 
     |next=A5-{{Top_10_2010:ByTheNumbers
 
     |next=A5-{{Top_10_2010:ByTheNumbers
Line 15: Line 15:
  
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
−
  {{Top_10:SummaryTableTemplate|exploitability=2|prevalence=3|detectability=1|impact=2|year=2017|language=en}}
+
  {{Top_10:SummaryTableTemplate|exploitability=1|prevalence=1|detectability=1|impact=2|year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Threat Agents: --->
 
<!--- Threat Agents: --->
 +
Consider the types of authorized users of your system. Are users restricted to certain functions and data? Are unauthenticated users allowed access to any functionality or data?
  
 
</td>
 
</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Attack Vectors --->
 
<!--- Attack Vectors --->
 +
Attackers, who are authorized users, simply change a parameter value to another resource they aren’t authorized for. Is access to this functionality or data granted?
  
 
</td>
 
</td>
 
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Security Weakness --->
 
<!--- Security Weakness --->
 +
For data, applications and APIs frequently use the actual name or key of an object when generating web pages. For functions, URLs and function names are frequently easy to guess. Applications and APIs don’t always verify the user is authorized for the target resource. This results in an access control flaw. Testers can easily manipulate parameters to detect such flaws. Code analysis quickly shows whether authorization is correct.
  
 
</td>
 
</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Technical Impacts --->
 
<!--- Technical Impacts --->
 +
Such flaws can compromise all the functionality or data that is accessible. Unless references are unpredictable, or access control is enforced, data and functionality can be stolen, or abused.
  
 
</td>
 
</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
<!--- Business Impacts  --->
 
<!--- Business Impacts  --->
 +
Consider the business value of the exposed data and functionality.
 +
 +
Also consider the business impact of public exposure of the vulnerability.
  
 
</td>
 
</td>
Line 40: Line 47:
  
 
{{Top_10:SubsectionTableBeginTemplate|year=2017|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=4|year=2017|language=en}}
 
{{Top_10:SubsectionTableBeginTemplate|year=2017|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=4|year=2017|language=en}}
 +
The best way to find out if an application is vulnerable to access control vulnerabilities is to verify that all data and function references have appropriate defenses. To determine if you are vulnerable, consider:
 +
# For '''data''' references, does the application ensure the user is authorized by using a reference map or access control check to ensure the user is authorized for that data?
 +
# For non-public '''function''' requests, does the application ensure the user is authenticated, and has the required roles or privileges to use that function?
 +
Code review of the application can verify whether these controls are implemented correctly and are present everywhere they are required. Manual testing is also effective for identifying access control flaws. 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=2017|language=en}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=4|year=2017|language=en}}
 +
Preventing access control flaws requires selecting an approach for protecting each function and each type of data (e.g., object number, filename).
 +
# '''Check access'''. Each use of a direct reference from an untrusted source must include an access control check to ensure the user is authorized for the requested resource.
 +
# '''Use per user or session indirect object references'''. This coding pattern 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. OWASP’s [[ESAPI]] includes both sequential and random access reference maps that developers can use to eliminate direct object references.
 +
# '''Automated verification'''. Leverage automation to verify proper authorization deployment. This is often custom.
  
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=4|year=2017|language=en}}
 +
'''Scenario #1:''' The application uses unverified data in a SQL call that is accessing account information:
  
−
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=4|year=2017|language=en}}
+
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<span style="color:red;">pstmt.setString( 1, request.getParameter("acct"));</span>
 +
ResultSet results = pstmt.executeQuery( );
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.
 +
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<nowiki>
 +
http://example.com/app/accountInfo?acct=</nowiki><span style="color:red;">notmyacct</span>
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
'''Scenario #2:''' An attacker simply force browses to target URLs. Admin rights are also required for access to the admin page.
 +
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<nowiki>http://example.com/app/getappInfo
 +
http://example.com/app/admin_getInfo</nowiki>{{Top_10_2010:ExampleEndTemplate}}
 +
If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is also a flaw.
  
  
Line 53: Line 80:
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=4|year=2017|language=en}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=4|year=2017|language=en}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}
−
*  
+
* [[Top_10_2007-Insecure_Direct_Object_Reference|OWASP Top 10-2007 on Insecure Direct Object References]]
 +
* [[Top_10_2007-Failure_to_Restrict_URL_Access|OWASP Top 10-2007 on Function Level Access Control]]
 +
* [https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/AccessReferenceMap.html ESAPI Access Reference Map API]
 +
* [https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/AccessController.html ESAPI Access Control API] (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )
 +
For additional access control requirements, see the [[ASVS|ASVS requirements area for Access Control (V4)]].
 +
 
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
−
*  
+
* [http://cwe.mitre.org/data/definitions/285.html CWE Entry 285 on Improper Access Control (Authorization)]
 +
* [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] (an example of a Direct Object Reference weakness)
  
 
{{Top_10_2013:BottomAdvancedTemplate
 
{{Top_10_2013:BottomAdvancedTemplate

Revision as of 22:32, 22 April 2017

'Bold text'Bold text

← A3-Sensitive Data Exposure
2017 Table of Contents

PDF version

A5-Broken Access Control →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability
EASY		 Prevalence
WIDESPREAD		 Detectability
EASY		 Impact
MODERATE		 Business ?

Consider the types of authorized users of your system. Are users restricted to certain functions and data? Are unauthenticated users allowed access to any functionality or data?

Attackers, who are authorized users, simply change a parameter value to another resource they aren’t authorized for. Is access to this functionality or data granted?

For data, applications and APIs frequently use the actual name or key of an object when generating web pages. For functions, URLs and function names are frequently easy to guess. Applications and APIs don’t always verify the user is authorized for the target resource. This results in an access control flaw. Testers can easily manipulate parameters to detect such flaws. Code analysis quickly shows whether authorization is correct.

Such flaws can compromise all the functionality or data that is accessible. Unless references are unpredictable, or access control is enforced, data and functionality can be stolen, or abused.

Consider the business value of the exposed data and functionality.

Also consider the business impact of public exposure of the vulnerability.

Am I Vulnerable To 'XML External Entities (XXE)'?

The best way to find out if an application is vulnerable to access control vulnerabilities is to verify that all data and function references have appropriate defenses. To determine if you are vulnerable, consider:

  1. For data references, does the application ensure the user is authorized by using a reference map or access control check to ensure the user is authorized for that data?
  2. For non-public function requests, does the application ensure the user is authenticated, and has the required roles or privileges to use that function?

Code review of the application can verify whether these controls are implemented correctly and are present everywhere they are required. Manual testing is also effective for identifying access control flaws. 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 'XML External Entities (XXE)'?

Preventing access control flaws requires selecting an approach for protecting each function and each type of data (e.g., object number, filename).

  1. Check access. Each use of a direct reference from an untrusted source must include an access control check to ensure the user is authorized for the requested resource.
  2. Use per user or session indirect object references. This coding pattern 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. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
  3. Automated verification. Leverage automation to verify proper authorization deployment. This is often custom.
Example Attack Scenarios

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

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

ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

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

Scenario #2: An attacker simply force browses to target URLs. Admin rights are also required for access to the admin page.

http://example.com/app/getappInfo http://example.com/app/admin_getInfo

If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is also a flaw.


References

OWASP

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

External

← A3-Sensitive Data Exposure
2017 Table of Contents

PDF version

A5-Broken Access Control →
© 2002-2017 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
Retrieved from "https://wiki.owasp.org/index.php?title=Top_10-2017_A5-Broken_Access_Control&oldid=229007"