Difference between revisions of "Access Control Cheat Sheet"

From OWASP
Jump to: navigation, search
m
 
(80 intermediate revisions by 8 users not shown)
Line 1: Line 1:
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
 
 
=Introduction=
 
=Introduction=
  
This article is focused on providing clear, simple, actionable guidance for providing Access Control security in your applications.
+
This article is focused on providing clear, simple, actionable guidance for providing access control security in your applications. The objective is to provide guidance to developers, reviewers, designers, architects on designing, creating and maintaining access controls in web applications
  
 
==What is Access Control / Authorization?==
 
==What is Access Control / Authorization?==
  
Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their defininitions are frequently confused.
+
Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their definitions are frequently confused.  Authentication is providing and validating identity. Authorization includes the execution rules that determines what functionality and data the user (or Principal) may access, ensuring the proper allocation of access rights after authentication is successful.
  
Access Control is the method or mechanism of authorization to enfore that requests to a system resource or functionality should be granted.
+
Web applications need access controls to allow users (with varying privileges) to use the application. They also need administrators to manage the applications access control rules and the granting of permissions or entitlements to users and other entities. Various access control design methodologies are available. To choose the most appropriate one, a risk assessment needs to be performed to identify threats and vulnerabilities specific to your application, so that the proper access control methodology is appropriate for your application.
  
'''Role Based Access Control (RBAC)''' is commonly used to manage permissions within an application. Permissions are assigned to users in a many to many relationship.
+
== Access Control Policy ==
  
'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an operating system.
+
Why do we need an access control policy for web development?
  
'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be dominated by the object being written to the system. To "read down", a subject's clearance level must govern the security level of the object being read. In this system, a subject may be able to write to an object, but will never be able to read it. This prevents malicious software from being able to leak data from different classification levels.  "Write up" prevents leakage from high to low.
+
The intention of having an access control policy is to ensure that security requirements are described clearly to architects, designers, developers and support team, such that access control functionality is designed and implemented in a consistent manner.
(See the [http://csrc.nist.gov/publications/history/dod85.pdf Orange Book] for more information about classification levels and confidentiality controls in "DAC" and "MAC".)
+
  
=Attacks on Access Control=
+
= Role Based Access Control (RBAC) =
  
Vertical Access Control Attacks - A standard user accessing administration functionality
+
In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base.
  
Horizontal Access Control attacks - Same role, but accessing another user's private data
+
The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as doctor, nurse, attendant, nurse, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.).
  
Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective
+
An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances. 
  
=Access Control Issues=
+
The advantages of using this methodology are:
*Many applications used the "All or Nothing" approach - Once authenticated, all users have equal privileges
+
*Roles are assigned based on organizational structure with emphasis on the organizational security policy
 +
*Easy to use
 +
*Easy to administer
 +
*Built into most frameworks
 +
*Aligns with security principles like segregation of duties and least privileges
  
*Authorization Logic often relies on Security by Obscurity (STO) by assuming:
+
Problems that can be encountered while using this methodology:
**Users will not find unlinked or hidden paths or functionality
+
*Documentation of the roles and accesses has to be maintained stringently.
**Users will not find and tamper with "obscured" client side parameters (i.e. "hidden" form fields, cookies, etc.)
+
*Multi-tenancy can not be implemented effectively unless there is a way to associate the roles with multi-tenancy capability requirements e.g. OU in Active Directory
+
*There is a tendency for scope creep to happen e.g. more accesses and privileges can be given than intended for. Or a user might be included in two roles if proper access reviews and subsequent revocation is not performed.
*Applications with multiple permission levels/roles often increases the possibility of conflicting permission sets resulting in unanticipated privileges
+
*Does not support data based access control
  
*Many administrative interfaces require only a password for authentication
+
The areas of caution while using RBAC are:
*Shared accounts combined with a lack of auditing and logging make it extremely difficult to differentiate between malicious and honest administrators
+
*Roles must be only be transferred or delegated using strict sign-offs and procedures.
*Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
+
*When a user changes his role to another one, the administrator must make sure that the earlier access is revoked such that at any given point of time, a user is assigned to only those roles on a need to know basis.
*Authorization/Access Control relies on client-side information (e.g., hidden fields)
+
*Assurance for RBAC must be carried out using strict access control reviews.
+
    <input type="text" name="fname" value="Derek">
+
    <input type="text" name="lname" value="Jeter">
+
    <input type="hidden" name="usertype" value="admin">
+
  
=Access Control Anti-Patterns=
+
= Discretionary Access Control (DAC) =
  
*Hard-coded role checks in application code
+
Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of information or any resource is able to change its permissions at his discretion (thus the name).
*Lack of centralized access control logic
+
*Untrusted data driving access control decisions
+
*Access control that is "open by default"
+
*Lack of addressing horizontal access control in a standardized way (if at all)
+
*Access control logic that needs to be manually added to every endpoint in code
+
  
==Hard Coded Roles==
+
A DAC framework can provide web application security administrators with the ability to implement fine grained access control. This model can be a basis for data based access control implementation
  
  if (user.isManager() ||
+
The advantages of using this model are:
      user.isAdministrator() ||
+
*Easy to use
      user.isEditor() ||
+
*Easy to administer
      user.isUser()) {
+
*Aligns to the principle of least privileges.
      //execute action
+
*Object owner has total control over access granted
  }
+
  
'''Hard Codes Roles can create several issues including:'''
+
Problems that can be encountered while using this methodology:
 +
*Documentation of the roles and accesses has to be maintained stringently.
 +
*Multi-tenancy can not be implemented effectively unless there is a way to associate the roles with multi-tenancy capability requirements e.g. OU in Active Directory
 +
*There is a tendency for scope creep to happen e.g. more accesses and privileges can be given than intended for.
  
*Making the policy of an application difficult to "prove" for audit or Q/A purposes
+
The areas of caution while using DAC are:
*Causing new code to be pushed each time an access control policy needs to be changed.
+
*While granting trusts
*They are fragile and easy to make mistakes
+
  
==Order Specific Operations==
+
*Assurance for DAC must be carried out using strict access control reviews.
  
Imagine the following parameters
+
= Mandatory Access Control (MAC) =
  
  http://example.com/buy?action=chooseDataPackage
+
Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications.  
  http://example.com/buy?action=customizePackage
+
  http://example.com/buy?action=makePayment
+
  http://example.com/buy?action=downloadData
+
  
'''Can an attacker control the sequence?'''
+
The advantages of using this methodology are:
 +
* Access to an object is based on the sensitivity of the object
 +
* Access based on need to know is strictly adhered to and scope creep has minimal possibility
 +
* Only an administrator can grant access
  
'''Can an attacker abuse this with concurency?'''
+
Problems that can be encountered while using this methodology:
 +
* Difficult and expensive to implement
 +
* Not agile
  
==Never Depend on Untrusted Data==
+
The areas of caution while using MAC are:
 +
* Classification and sensitivity assignment at an appropriate and pragmatic level
 +
* Assurance for MAC must be carried out to ensure that the classification of the objects is at the appropriate level.
  
*Never trust user data for access control decisions
+
= Permission Based Access Control =
*Never make access control decisions in JavaScript
+
*Never depend on the order of values sent from the client
+
*Never make authorization decisions based solely on
+
**hidden fields
+
**cookie values
+
**form parameters
+
**URL parameters
+
**anything else from the request
+
+
  
=Attacking Access Controls=
+
The key concept in Permission Based Access Control is the abstraction of application actions into a set of ''permissions''. A ''permission'' may be represented simply as a string based name, for example "READ". Access decisions are made by checking if the current user ''has'' the permission associated with the requested application action.
  
*Elevation of privileges
+
The ''has'' relationship between the user and permission may be satisfied by creating a direct relationship between the user and permission (called a ''grant''), or an indirect one. In the indirect model the permission ''grant'' is to an intermediate entity such as ''user group''. A user is considered a member of a ''user group'' if and only if the user ''inherits'' permissions from the ''user group''. The indirect model makes it easier to manage the permissions for a large number of users, since changing the permissions assigned to the user group affects all members of the user group.
*Disclosure of confidential data - Compromising admin-level accounts often result in access to a user's confidential data
+
*Data tampering - Privilege levels do not distinguish users who can only view data and users permitted to modify data
+
  
=Testing for Broken Access Control=
+
In some Permission Based Access Control systems that provide fine-grained domain object level access control, permissions may be grouped into ''classes''. In this model it is assumed that each domain object in the system can be associated with a ''class'' which determines the permissions applicable to the respective domain object. In such a system a "DOCUMENT" class may be defined with the permissions "READ", "WRITE" and DELETE"; a "SERVER" class may be defined with the permissions "START", "STOP", and "REBOOT".
  
*Attempt to access administrative components or functions as an anonymous or regular user
+
= Authors and Primary Editors =
**Scour HTML source for “interesting” hidden form fields
+
**Test web accessible directory structure for names like admin, administrator, manager, etc (i.e. attempt to directly browse to “restricted” areas)
+
*Determine how administrators are authenticated. Ensure that adequate authentication is used and enforced
+
*For each user role, ensure that only the appropriate pages or components are accessible for that role.
+
*Login as a low-level user, browse history for a higher level user’s cache, load the page to see if the original authorization is passed to a previous session.
+
*If able to compromise administrator-level account, test for all other common web application vulnerabilities (poor input validation, privileged database access, etc)
+
  
=Defenses Against Access Control Attacks=
+
Shruti Kulkarni - shruti.kulkarni [at] owasp.org<br/>
 +
Adinath Raveendra Raj - adinath [at] acciente.com<br/>
 +
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org<br/>
 +
Jim Manico - jim [at] owasp.org<br/>
  
*Implement role based access control to assign permissions to application users for vertical access control requirements
+
= Other Cheatsheets =
*Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
+
{{Cheatsheet_Navigation_Body}}
*Avoid assigning permissions on a per-user basis
+
*Perform consistent authorization checking routines on all application pages
+
*Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis
+
*Where possible restrict administrator access to machines located on the local area network (i.e. it’s best to avoid remote administrator access from public facing access points)
+
*Log all failed access authorization requests to a secure location for review by administrators
+
*Perform reviews of failed login attempts on a periodic basis
+
*Utilize the strengths and functionality provided by the SSO solution you chose
+
  
=Best Practices=
+
__NOTOC__ <headertabs />
 
+
[[Category:Cheatsheets]]
==Best Practice: Code to the Activity==
+
 
+
  if (AC.hasAccess(ARTICLE_EDIT)) {
+
      //execute activity
+
  }
+
*Code it once, never needs to change again
+
*Implies policy is persisted/centralized in some way
+
*Avoid assigning permissions on a per-user basis
+
*Requires more design/work up front to get right
+
 
+
==Best Practice: Centralized ACL Controller==
+
 
+
*Define a centralized access controller
+
      ACLService.isAuthorized(ACTION_CONSTANT)
+
      ACLService.assertAuthorized(ACTION_CONSTANT)
+
*Access control decisions go through these simple API’s
+
*Centralized logic to drive policy behavior and persistence
+
*May contain data-driven access control policy information
+
*Policy language needs to support ability to express both access rights and prohibitions
+
 
+
==Best Practice: Using a Centralized Access Controller==
+
 
+
*In Presentation Layer
+
 
+
      if (isAuthorized(VIEW_LOG_PANEL))
+
      {
+
          Here are the logs
+
          <%=getLogs();%/>
+
      }
+
+
*In Controller
+
 
+
      try (assertAuthorized(DELETE_USER))
+
      {
+
          deleteUser();
+
      }
+
 
+
==Best Practice: Verifying policy server-side==
+
 
+
*Keep user identity verification in session
+
*Load entitlements server side from trusted sources
+
*Force authorization checks on ALL requests
+
**JS file, image, AJAX and FLASH requests as well!
+
**Force this check using a filter if possible
+
 
+
=SQL Integrated Access Control=
+
 
+
'''Example Feature'''
+
 
+
    http://mail.example.com/viewMessage?msgid=2356342
+
 
+
'''This SQL would be vulnerable to tampering'''
+
 
+
  select * from messages where messageid = 2356342
+
 
+
'''Ensure the owner is referenced in the query!'''
+
 
+
  select * from messages where messageid = 2356342 AND messages.message_owner =
+
 
+
=Access Control Positive Patterns=
+
 
+
*Code to the activity, not the role
+
*Centralize access control logic
+
*Design access control as a filter
+
*Deny by default, fail securely
+
*Build centralized access control mechanism
+
*Apply same core logic to presentation and server-side access control decisions
+
*Determine access control through Server-side trusted data
+
 
+
=Data Contextual Access Control=
+
 
+
'''Data Contextual / Horizontal Access Control API examples'''
+
 
+
    ACLService.isAuthorized(EDIT_ORG, 142)
+
    ACLService.assertAuthorized(VIEW_ORG, 900)
+
 
+
Long Form
+
 
+
    isAuthorized(user, EDIT_ORG, Organization.class, 14)
+
+
*Essentially checking if the user has the right role in the context of a specific object
+
*Centralize access control logic
+
*Protecting data at the lowest level!
+
 
+
= Related Articles  =
+
 
+
{{Cheatsheet_Navigation}}
+
 
+
=Authors and Primary Editors=
+
 
+
Jim Manico - jim [at] owasp dot org
+
Fred Donovan - fred.donovan [at] owasp dot org
+

Latest revision as of 12:38, 6 March 2016

[edit]

This article is focused on providing clear, simple, actionable guidance for providing access control security in your applications. The objective is to provide guidance to developers, reviewers, designers, architects on designing, creating and maintaining access controls in web applications

What is Access Control / Authorization?

Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their definitions are frequently confused. Authentication is providing and validating identity. Authorization includes the execution rules that determines what functionality and data the user (or Principal) may access, ensuring the proper allocation of access rights after authentication is successful.

Web applications need access controls to allow users (with varying privileges) to use the application. They also need administrators to manage the applications access control rules and the granting of permissions or entitlements to users and other entities. Various access control design methodologies are available. To choose the most appropriate one, a risk assessment needs to be performed to identify threats and vulnerabilities specific to your application, so that the proper access control methodology is appropriate for your application.

Access Control Policy

Why do we need an access control policy for web development?

The intention of having an access control policy is to ensure that security requirements are described clearly to architects, designers, developers and support team, such that access control functionality is designed and implemented in a consistent manner.

In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base.

The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as doctor, nurse, attendant, nurse, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.).

An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances.

The advantages of using this methodology are:

  • Roles are assigned based on organizational structure with emphasis on the organizational security policy
  • Easy to use
  • Easy to administer
  • Built into most frameworks
  • Aligns with security principles like segregation of duties and least privileges

Problems that can be encountered while using this methodology:

  • Documentation of the roles and accesses has to be maintained stringently.
  • Multi-tenancy can not be implemented effectively unless there is a way to associate the roles with multi-tenancy capability requirements e.g. OU in Active Directory
  • There is a tendency for scope creep to happen e.g. more accesses and privileges can be given than intended for. Or a user might be included in two roles if proper access reviews and subsequent revocation is not performed.
  • Does not support data based access control

The areas of caution while using RBAC are:

  • Roles must be only be transferred or delegated using strict sign-offs and procedures.
  • When a user changes his role to another one, the administrator must make sure that the earlier access is revoked such that at any given point of time, a user is assigned to only those roles on a need to know basis.
  • Assurance for RBAC must be carried out using strict access control reviews.

Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of information or any resource is able to change its permissions at his discretion (thus the name).

A DAC framework can provide web application security administrators with the ability to implement fine grained access control. This model can be a basis for data based access control implementation

The advantages of using this model are:

  • Easy to use
  • Easy to administer
  • Aligns to the principle of least privileges.
  • Object owner has total control over access granted

Problems that can be encountered while using this methodology:

  • Documentation of the roles and accesses has to be maintained stringently.
  • Multi-tenancy can not be implemented effectively unless there is a way to associate the roles with multi-tenancy capability requirements e.g. OU in Active Directory
  • There is a tendency for scope creep to happen e.g. more accesses and privileges can be given than intended for.

The areas of caution while using DAC are:

  • While granting trusts
  • Assurance for DAC must be carried out using strict access control reviews.

Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications.

The advantages of using this methodology are:

  • Access to an object is based on the sensitivity of the object
  • Access based on need to know is strictly adhered to and scope creep has minimal possibility
  • Only an administrator can grant access

Problems that can be encountered while using this methodology:

  • Difficult and expensive to implement
  • Not agile

The areas of caution while using MAC are:

  • Classification and sensitivity assignment at an appropriate and pragmatic level
  • Assurance for MAC must be carried out to ensure that the classification of the objects is at the appropriate level.

The key concept in Permission Based Access Control is the abstraction of application actions into a set of permissions. A permission may be represented simply as a string based name, for example "READ". Access decisions are made by checking if the current user has the permission associated with the requested application action.

The has relationship between the user and permission may be satisfied by creating a direct relationship between the user and permission (called a grant), or an indirect one. In the indirect model the permission grant is to an intermediate entity such as user group. A user is considered a member of a user group if and only if the user inherits permissions from the user group. The indirect model makes it easier to manage the permissions for a large number of users, since changing the permissions assigned to the user group affects all members of the user group.

In some Permission Based Access Control systems that provide fine-grained domain object level access control, permissions may be grouped into classes. In this model it is assumed that each domain object in the system can be associated with a class which determines the permissions applicable to the respective domain object. In such a system a "DOCUMENT" class may be defined with the permissions "READ", "WRITE" and DELETE"; a "SERVER" class may be defined with the permissions "START", "STOP", and "REBOOT".

Shruti Kulkarni - shruti.kulkarni [at] owasp.org
Adinath Raveendra Raj - adinath [at] acciente.com
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org
Jim Manico - jim [at] owasp.org