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"
m (underlined all links and Scenario #1/2; deleted some empty lines) |
m (corrected line break in Scenario#2, coulored the admin URI in red, changed the line break in Scenario#1 to the same style as Scenarion#2) |
||
| Line 62: | Line 62: | ||
<u>'''Scenario #1:'''</u> The application uses unverified data in a SQL call that is accessing account information: | <u>'''Scenario #1:'''</u> The application uses unverified data in a SQL call that is accessing account information: | ||
| − | {{Top_10_2010:ExampleBeginTemplate|year=2017}}<span style="color:red;">pstmt.setString( 1, request.getParameter("acct"));</span> | + | {{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><span style="color:red;"><nowiki> |
| − | ResultSet results = pstmt.executeQuery( ); | + | pstmt.setString(1, request.getParameter("acct"));</nowiki></span><br/><nowiki> |
| + | 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}}<nowiki> | + | {{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><nowiki> |
| − | http://example.com/app/accountInfo?acct=</nowiki><span style="color:red;">notmyacct</span> | + | 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. | <u>'''Scenario #2:'''</u> 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 | + | {{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><nowiki> |
| − | http://example.com/app/ | + | http://example.com/app/getappInfo</nowiki><br/><nowiki> |
| + | http://example.com/app/</nowiki><span style="color:red;">admin_getappInfo</span></b> | ||
| + | {{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 also a flaw. | ||
Revision as of 21:18, 23 April 2017
| 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:
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).
|
|
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_getappInfo 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
|
