Security - Missing Function Level Access Control

security

https://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html
https://www.owasp.org/index.php/Guide_to_Authorization
https://www.owasp.org/index.php/Testing_for_Path_Traversal
https://www.owasp.org/index.php/Forced_browsing
http://cwe.mitre.org/data/definitions/285.html

// Security - Missing Function Level Access Control:

Anyone with network access can send your application a request. Could anonymous 
users access private functionality or regular users a privileged function?  Can 
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.

Such flaws allow attackers to access unauthorized functionality. Administrative 
functions are key targets for this type of attack.

Assigning roles and privileges is one thing.  Verifying that the user actually 
has the privilege to execute that function is another thing.

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 server side authentication or authorization checks missing?

3. Are server side checks done that solely rely on information provided by the 
   attacker?

Using a proxy, browse your application with a privileged role. Then revisit 
restricted pages using a less privileged role. If the server responses are 
alike, you're probably vulnerable. Some testing proxies directly support this 
type of analysis.  They key here is that we use a proxy to automatically log the 
URL so that we can get a list of URLs, and then access those URLs as anonymous 
users or user with lower privilege.

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 the codebase to find where that pattern is not being 
followed.  We can also step through the code with a debugger and see if it is 
doing any authorization at all.

Automated tools are unlikely to find these problems.

Your application should have a consistent and easy to analyze authorization 
module that is invoked from all of 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.

Functions can usually be expressed as URLs, and these URLs are often kept in the 
role / privilege table.  It is possible that we can write a generic filter that 
sit in front of our main application and check to see if this user was assigned 
this functionality.  We can query the roles / privileges table to retrieve a 
list of URLs that this user have access to, and match each of these URLs against 
the URL of the current request.

If the URL is common for several actions, then we may need to perform the 
authorization step for each action.  Maybe we can extend the filter to check 
both the URL and the HTTP method (we will need to capture the HTTP method as 
part of the roles / privileges table).
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License