Difference between revisions of "Access Control Cheat Sheet"

From OWASP
Jump to: navigation, search
m (Access Control Vulnerabilities)
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
=Introduction=
 
=Introduction=
  
<b> DRAFT CHEAT SHEET - WORK IN PROGRESS</b>
+
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
 
 
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 definitions are frequently confused.  Authentication is providing and validating identity. In a system that uses a simple username and password scheme, the authentication process collects the username and validates the identity using the password.  Authorization is the execution of access control properties, ensuring the proper allocation of access rights once authentication is successful.
+
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 enforce 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.
  
We need to know that entities that request access to resources are subjects and the resource is an object.
+
== Access Control Policy ==
Unless otherwise designed to, web applications need access controls to allow users (with varying privileges) to use the applications and administrators to manage the application. Various access control methodologies are available. To choose the most appropriate one, a risk assessment needs to be performed  to identify threats and vulnerabilities, so that the identified methodology brings down the risk value to an acceptable level.
 
 
 
==Access Control Policy ==
 
  
 
Why do we need an access control policy for web development?
 
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 accesses are designed and implemented in a consistent manner for web application projects within an organisation.
+
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.
 
 
Guidelines in maintaining an access control policy
 
 
 
1. Maintain a policy that lists down the activities that are important from an organisation perspective, to be followed.
 
 
 
For example:
 
The policy may document the following:
 
      a. set requirements on risk assessments as a starting point for access control design.
 
      b. identify the access control model based on the output of risk assessments
 
      c. If any access determination on client side has to have additional controls
 
 
 
2.Review the Access Control Control policy at least once a year to make sure that the activities set up in #1 hold good
 
 
 
==Risk assess the functionality to arrive at a model for implementation of access control ==
 
 
 
Risk assess the application before deciding on the methodology for access controls. An application that processes top secret data might need mandatory access control, whilst a finance application used within the corporate might require role based access control along with frequent access reviews
 
 
 
One way to do this is:
 
 
 
1. Identify the data elements that are objects.  
 
  
2. Identify confidentiality, integrity and availability values of the data elements
+
= Role Based Access Control (RBAC) =
  
3. Identify the impact of breach of confidentiality, integrity and availability values of the data elements on the organisation.
 
 
4. Identify the probability of a breach occuring
 
 
Based on the impact and probability factors:
 
 
1. Identify the appropriate access control model
 
 
2. Identify the segments that need access control
 
 
3. Following are examples of the segments that need to be considered
 
          a. APIs
 
          b. Web application
 
          c. Servers
 
          d. Network
 
          e. Database
 
          f. Physical perimeter
 
 
== Role Based Access Control (RBAC) ==
 
 
In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base.  
 
In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base.  
  
Line 83: Line 39:
 
*Roles must be only be transferred or delegated using strict sign-offs and procedures.
 
*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.
 
*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.
+
*Assurance for RBAC must be carried out using strict access control reviews.
 
 
OWASP has a role based access control implementation project, [[OWASP_PHPRBAC_Project|OWASP RBAC Project]].
 
  
== Discretionary Access Control (DAC) ==
+
= Discretionary Access Control (DAC) =
  
 
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).
 
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).
Line 101: Line 55:
 
Problems that can be encountered while using this methodology:
 
Problems that can be encountered while using this methodology:
 
*Documentation of the roles and accesses has to be maintained stringently.
 
*Documentation of the roles and accesses has to be maintained stringently.
*Vulnerable to Trojan horses
 
 
*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
 
*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.  
 
*There is a tendency for scope creep to happen e.g. more accesses and privileges can be given than intended for.  
Line 110: Line 63:
 
*Assurance for DAC must be carried out using strict access control reviews.
 
*Assurance for DAC must be carried out using strict access control reviews.
  
== Mandatory Access Control (MAC) ==
+
= Mandatory Access Control (MAC) =
  
 
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.  
 
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:
 
The advantages of using this methodology are:
*Access to an object is based on the sensitivity of the object
+
* 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
+
* Access based on need to know is strictly adhered to and scope creep has minimal possibility
*Only an administrator can grant access  
+
* Only an administrator can grant access  
  
 
Problems that can be encountered while using this methodology:
 
Problems that can be encountered while using this methodology:
*Difficult and expensive to implement
+
* Difficult and expensive to implement
*Not agile
+
* Not agile
  
 
The areas of caution while using MAC are:
 
The areas of caution while using MAC are:
*Classification and sensitivity assignment at an appropriate and pragmatic level
+
* 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.
Assurance for MAC must be carried out to ensure that the classification of the objects is at the appropriate level.
 
 
 
== Attribute Based Access Control (ABAC) ==
 
 
 
[http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf NIST Special Publication (SP) 800-162 (Final)]
 
 
 
=Attacks on Access Control=
 
 
 
*Elevation of privileges
 
*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
 
 
 
Following are the access control attacks that can take place:
 
 
 
Vertical Access Control Attacks:
 
*A subject with lower privileges accesses objects that are designed for subjects with higher privileges.
 
 
 
Examples of Vertical Access Control Attacks are:
 
 
 
1. A service is running for a web application as a local user. An exploited vulnerability (for example buffer overflow) allows the attacker to elevate the service's privileges to local admin.
 
 
 
2. Improper validation of a user allows the user to elevate privileges to admin on a web application, via cross site scripting
 
 
 
3. Jailbroken devices allow users to have more access on the mobile device. A malicious program can elevate its privileges to gather contact details on a phone
 
 
 
4. Controlling the coredump file can allow an attacker to run any program with elevated privileges
 
 
 
5. An attacker gains admin access on the database via a web application as the application id uses admin id for all levels of accesses.
 
 
 
Horizontal Access Control attacks:
 
 
 
* A subject access objects with same privileges and the one that is designed for other subjects.
 
 
 
Examples of Horizontal Access Control Attacks are:
 
 
 
1. A user of a bank application uses a predictable session id to log in and perform bank transfers.
 
 
 
2. A user logs into a shopping application using a guessable password and directs the purchases to his/her address without the actual user knowing about this
 
 
 
3. An employee logs into the intranet portal and accesses salary details of a colleague while the colleague has logged in and not locked the work station
 
  
Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective
+
= Permission Based Access Control =
  
 +
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.
  
= References =
+
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".
* [[Testing for Authorization]]
 
  
 
= Authors and Primary Editors =
 
= Authors and Primary Editors =
  
 
Shruti Kulkarni - shruti.kulkarni [at] owasp.org<br/>
 
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/>
 
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org<br/>
 
Jim Manico - jim [at] owasp.org<br/>
 
Jim Manico - jim [at] owasp.org<br/>
  
== Other Cheatsheets ==
+
= Other Cheatsheets =
 
{{Cheatsheet_Navigation_Body}}
 
{{Cheatsheet_Navigation_Body}}
  
 
__NOTOC__ <headertabs />
 
__NOTOC__ <headertabs />
 
[[Category:Cheatsheets]]
 
[[Category:Cheatsheets]]

Revision as of 13:38, 6 March 2016

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