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
m (T.Gigler moved page Top 10 2017-A4-Broken Access Control to Top 10-2017 A4-Broken Access Control: OWASP Top 10-2017 Release)
m (Editorial changes e.g. line feeds)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
−
     |usenext=2013NextLink
+
     |useprev=2017PrevLink
−
     |next=A5-{{Top_10_2010:ByTheNumbers
+
     |prev=A4-{{Top_10_2010:ByTheNumbers
−
              |5
+
        |4
−
              |year=2017
+
        |year=2017
−
              |language=en}}
+
        |language=en
−
     |useprev=2013PrevLink
+
    }}
−
     |prev=A3-{{Top_10_2010:ByTheNumbers
+
     |usenext=2017NextLink
−
              |3
+
     |next=A6-{{Top_10_2010:ByTheNumbers
−
              |year=2017
+
        |6
−
              |language=en}}
+
        |year=2017
 +
        |language=en
 +
    }}
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
−
 
+
<!--- 2017 Broken Access Control --->
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
−
{{Top_10:SummaryTableTemplate|exploitability=1|prevalence=1|detectability=1|impact=2|year=2017|language=en}}
+
{{Top_10-2017:SummaryTableTemplate|exploitability=2 |prevalence=2 |detectability=2 |impact=3 |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 colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
−
<!--- Threat Agents: --->
+
<!--- Threat Agent: --->
−
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?
+
Exploitation of access control is a core skill of attackers. <u>[[Source_Code_Analysis_Tools|SAST]]</u> and <u>[[:Category:Vulnerability_Scanning_Tools|DAST]]</u> tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. </td>
−
 
+
    <td colspan=2  {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
−
</td>
+
<!--- Security Weakness: --->
−
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers.<br/>Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs PUT, etc), controller, direct object references, etc. </td>
−
<!--- Attack Vectors --->
+
    <td colspan=2  {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
−
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?
+
<!--- Impacts: --->
−
 
+
The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record.<br/>The business impact depends on the protection needs of the application and data. </td>
−
</td>
 
−
    <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
−
<!--- 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 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
−
<!--- 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 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
−
<!--- Business Impacts  --->
 
−
Consider the business value of the exposed data and functionality.
 
−
 
 
−
Also consider the business impact of public exposure of the vulnerability.
 
−
 
 
−
</td>
 
 
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
 
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
  
−
{{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|type=main}}
−
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:
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=isTheApplicationVulnerable|position=firstLeft|year=2017|language=en}}
−
# 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?
+
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Common access control vulnerabilities include:
−
# For non-public '''function''' requests, does the application ensure the user is authenticated, and has the required roles or privileges to use that function?
+
* Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.
−
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.
+
* Allowing the primary key to be changed to another's users record, permitting viewing or editing someone else's account.
−
 
+
* Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.
 +
* Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation
 +
* CORS misconfiguration allows unauthorized API access.
 +
* Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.
  
−
{{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=howToPrevent|position=right|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).
+
Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.
−
# '''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.
+
* With the exception of public resources, deny by default.
−
# '''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 <u>[[ESAPI]]</u> includes both sequential and random access reference maps that developers can use to eliminate direct object references.
+
* Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
−
# '''Automated verification'''. Leverage automation to verify proper authorization deployment. This is often custom.
+
* Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
 +
* Unique application business limit requirements should be enforced by domain models.
 +
* Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
 +
* Log access control failures, alert admins when appropriate (e.g. repeated failures).
 +
* Rate limit API and controller access to minimize the harm from automated attack tooling.
 +
* JWT tokens should be invalidated on the server after logout.
 +
Developers and QA staff should include functional access control unit and integration tests.
  
−
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=4|year=2017|language=en}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=exampleAttackScenarios|position=left|year=2017|language=en}}
−
<u>'''Scenario #1:'''</u> The application uses unverified data in a SQL call that is accessing account information:
 
  
 +
<b>Scenario #1</b>: The application uses unverified data in a SQL call that is accessing account information:
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><span style="color:red;"><nowiki>
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><span style="color:red;"><nowiki>
 
pstmt.setString(1, request.getParameter("acct"));</nowiki></span><br/><nowiki>
 
pstmt.setString(1, request.getParameter("acct"));</nowiki></span><br/><nowiki>
 
ResultSet results = pstmt.executeQuery( );</nowiki></b>
 
ResultSet results = pstmt.executeQuery( );</nowiki></b>
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{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.
+
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}}<b><nowiki>
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><nowiki>
 
http://example.com/app/accountInfo?acct=</nowiki><span style="color:red;">notmyacct</span></b>
 
http://example.com/app/accountInfo?acct=</nowiki><span style="color:red;">notmyacct</span></b>
 
{{Top_10_2010:ExampleEndTemplate}}<br>
 
{{Top_10_2010:ExampleEndTemplate}}<br>
  
−
<u>'''Scenario #2:'''</u> An attacker simply force browses to target URLs. Admin rights are also required for access to the admin page.
+
<b>Scenario #2</b>: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><nowiki>
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><nowiki>
 
http://example.com/app/getappInfo</nowiki><br/><nowiki>
 
http://example.com/app/getappInfo</nowiki><br/><nowiki>
 
http://example.com/app/</nowiki><span style="color:red;">admin_getappInfo</span></b>
 
http://example.com/app/</nowiki><span style="color:red;">admin_getappInfo</span></b>
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{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.
+
If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.
  
−
{{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|year=2017|language=en}}
−
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}
+
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017|language=en}}
−
* <u>[[Top_10_2007-Insecure_Direct_Object_Reference|OWASP Top 10-2007 on Insecure Direct Object References]]</u>
+
* <u>[[OWASP_Proactive_Controls#6:_Implement_Access_Controls|OWASP Proactive Controls: Access Controls]]</u>
−
* <u>[[Top_10_2007-Failure_to_Restrict_URL_Access|OWASP Top 10-2007 on Function Level Access Control]]</u>
+
* <u>[[:Category:OWASP_Application_Security_Verification_Standard_Project#tab=Home|OWASP Application Security Verification Standard: V4 Access Control]]</u>
−
* <u>[https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/AccessReferenceMap.html ESAPI Access Reference Map API]</u>
+
* <u>[[Testing_for_Authorization|OWASP Testing Guide: Authorization Testing]]</u>
−
* <u>[https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/AccessController.html ESAPI Access Control API]</u> (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )
+
* <u>[[Access_Control_Cheat_Sheet|OWASP Cheat Sheet: Access Control]]</u>
−
For additional access control requirements, see the <u>[[ASVS|ASVS requirements area for Access Control (V4)]]</u>.
 
  
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
−
* <u>[http://cwe.mitre.org/data/definitions/285.html CWE Entry 285 on Improper Access Control (Authorization)]</u>
+
* <u>[https://cwe.mitre.org/data/definitions/22.html CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')]</u>
−
* <u>[http://cwe.mitre.org/data/definitions/639.html CWE Entry 639 on Insecure Direct Object References]</u>
+
* <u>[https://cwe.mitre.org/data/definitions/284.html CWE-284: Improper Access Control (Authorization)]</u>
−
* <u>[http://cwe.mitre.org/data/definitions/22.html CWE Entry 22 on Path Traversal]</u> (an example of a Direct Object Reference weakness)
+
* <u>[https://cwe.mitre.org/data/definitions/285.html CWE-285: Improper Authorization]</u>
 +
* <u>[https://cwe.mitre.org/data/definitions/639.html CWE-639: Authorization Bypass Through User-Controlled Key]</u>
 +
* <u>[https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties PortSwigger: Exploiting CORS misconfiguration]</u>
  
 
{{Top_10_2013:BottomAdvancedTemplate
 
{{Top_10_2013:BottomAdvancedTemplate
−
     |type={{Top_10_2010:StyleTemplate}}
+
     |type=box
−
     |usenext=2013NextLink
+
     |useprev=2017PrevLink
−
     |next=A5-{{Top_10_2010:ByTheNumbers
+
     |prev=A4-{{Top_10_2010:ByTheNumbers
−
              |5
+
        |4
−
              |year=2017
+
        |year=2017
−
              |language=en}}
+
        |language=en
−
     |useprev=2013PrevLink
+
    }}
−
     |prev=A3-{{Top_10_2010:ByTheNumbers
+
     |usenext=2017NextLink
−
              |3
+
     |next=A6-{{Top_10_2010:ByTheNumbers
−
              |year=2017
+
        |6
−
              |language=en}}
+
        |year=2017
 +
        |language=en
 +
    }}
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
  
−
[[Category:OWASP Top Ten Project]]
+
<!-- [[Category:OWASP Top Ten Project]] -->

Latest revision as of 16:38, 1 January 2018

← A4-XML External Entities (XXE)
2017 Table of Contents

PDF version

A6-Security Misconfiguration →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability: 2
 Prevalence: 2
 Detectability: 2
 Technical: 3
 Business ?
Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers.
Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs PUT, etc), controller, direct object references, etc. 		The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record.
The business impact depends on the protection needs of the application and data.
Is the Application Vulnerable?

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Common access control vulnerabilities include:

  • Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.
  • Allowing the primary key to be changed to another's users record, permitting viewing or editing someone else's account.
  • Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.
  • Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation
  • CORS misconfiguration allows unauthorized API access.
  • Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.
How to Prevent

Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.

  • With the exception of public resources, deny by default.
  • Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
  • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
  • Unique application business limit requirements should be enforced by domain models.
  • Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
  • Log access control failures, alert admins when appropriate (e.g. repeated failures).
  • Rate limit API and controller access to minimize the harm from automated attack tooling.
  • JWT tokens should be invalidated on the server after logout.

Developers and QA staff should include functional access control unit and integration tests.

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 required for access to the admin page.

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

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

References

OWASP

External

← A4-XML External Entities (XXE)
2017 Table of Contents

PDF version

A6-Security Misconfiguration →
© 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=236485"