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
(Prepare OWASP Top 10-2017 Release (Content)) |
m (Editorial changes e.g. line feeds) |
||
| Line 24: | Line 24: | ||
<td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}> | <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Security Weakness: ---> | <!--- Security Weakness: ---> | ||
| − | 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. </td> | + | 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> |
<td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}> | <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Impacts: ---> | <!--- Impacts: ---> | ||
| − | 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. </td> | + | 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> |
{{Top_10_2010:SummaryTableEndTemplate|year=2017}} | {{Top_10_2010:SummaryTableEndTemplate|year=2017}} | ||
| Line 50: | Line 50: | ||
* Rate limit API and controller access to minimize the harm from automated attack tooling. | * Rate limit API and controller access to minimize the harm from automated attack tooling. | ||
* JWT tokens should be invalidated on the server after logout. | * 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=exampleAttackScenarios|position=left|year=2017|language=en}} | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=exampleAttackScenarios|position=left|year=2017|language=en}} | ||
Latest revision as of 16:38, 1 January 2018
| 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:
|
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.
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 |
