Top 10 2013-A7-Missing Function Level Access Control

Revision as of 09:27, 9 June 2013 by T.Gigler (talk | contribs) (brighter background for 'Top_10_2010:ExampleBeginTemplate' => added '|year=2013')

Jump to: navigation, search

NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.

[[Top 10 {{{year}}}-Sensitive Data Exposure|← Sensitive Data Exposure]]
[[Top 10 {{{year}}}-Table of Contents | {{{year}}} Table of Contents]]

[[Top_10_{{{year}}}-Top 10|{{{year}}} Top 10 List]]

[[Top 10 {{{year}}}-Cross-Site Request Forgery (CSRF)|Cross-Site Request Forgery (CSRF) →]]
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
Application / Business Specific
Anyone with network access can send your application a request. Could anonymous users access private functionality or regular users a privileged function? . Attacker, who is an authorized system user, simply changes the URL or a parameter to a privileged function. Is access granted? Anonymous users could access private functions that aren’t protected. Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack.

Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. Consider the business value of the exposed functions and the data they process.

Also consider the impact to your reputation if this vulnerability became public.

Am I Vulnerable To 'Missing Function Level Access Control'?

The best way to find out if an application has failed to properly restrict function level access is to verify every application function:

  1. Does the UI show navigation to unauthorized functions?
  2. Are proper authentication and authorization checked?
  3. Are checks done on the server without relying on information provided by the attacker?

Using a proxy, browse your application with a privileged role. Then revisit restricted pages while logged in as a less privileged role. Some proxies support this type of analysis.

You can also check the access control implementation in the code. Try following a single privileged request through the code and verifying the authorization pattern. Then search to ensure that the pattern is followed throughout.

Automated tools are unlikely to find these problems.

How Do I Prevent 'Missing Function Level Access Control'?

Your application should have a consistent and easily analyzable authorization module that is invoked from all your business functions. Frequently, such protection is provided by one or more components external to the application code.

  1. Think about the process for managing entitlements and ensure you can update and audit easily. Don’t hard code.
  2. The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
  3. If the function is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

NOTE: Most web applications don’t display links and buttons to unauthorized functions, but this “presentation layer access control” doesn’t actually provide protection. You must also implement checks in the controller or business logic.

Example Attack Scenarios

Scenario #1: The attacker simply force browses to target URLs. The following URLs require authentication. Admin rights are also required for access to the “admin_getappInfo” page.

If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is also a flaw, and may lead the attacker to more improperly protected admin pages.

Scenario #2: A page provides an ‘action ‘parameter to specify the function being invoked, and different actions require different roles. If these roles aren’t enforced, that’s a flaw.



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


[[Top 10 {{{year}}}-Sensitive Data Exposure|← Sensitive Data Exposure]]
[[Top 10 {{{year}}}-Table of Contents | {{{year}}} Table of Contents]]

[[Top_10_{{{year}}}-Top 10|{{{year}}} Top 10 List]]

[[Top 10 {{{year}}}-Cross-Site Request Forgery (CSRF)|Cross-Site Request Forgery (CSRF) →]]

© 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
[[Category:OWASP Top Ten {{{year}}} Project]]