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

Access Control Cheat Sheet

From OWASP
Revision as of 15:47, 13 October 2015 by Shruti kulkarni (talk | contribs) (Best Practice: Segregation of Duties)

Jump to: navigation, search

DRAFT CHEAT SHEET - WORK IN PROGRESS

Introduction

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. 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.

Access Control is the method or mechanism of authorization to enforce that requests to a system resource or functionality should be granted.

We need to know that entities that request access to resources are subjects and the resource is an object. 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.

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

3. Identify the impact of breach of confidentiality, integrity and availability values of the data elements on the organisation.

Based on the impact:

1. Identify the appropriate access control model

2. Identify the segments that need access control

         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.

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.

OWASP has a role based access control implementation project, OWASP RBAC Project.

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).

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.
  • 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
  • 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)

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.

Attribute Based Access Control (ABAC)

NIST Special Publication (SP) 800-162 (Final)

Attacks on Access Control

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

Access Control Vulnerabilities

  • Many applications used the "All or Nothing" approach - Once authenticated, all users have equal privileges
  • Authorization Logic often relies on Security by Obscurity (STO) by assuming:
    • Users will not find unlinked or hidden paths or functionality
    • Users will not find and tamper with "obscured" client side parameters (i.e. "hidden" form fields, cookies, etc.)
  • Applications with multiple permission levels/roles often increases the possibility of conflicting permission sets resulting in unanticipated privileges
  • Many administrative interfaces require only a password for authentication
  • Shared accounts combined with a lack of auditing and logging make it extremely difficult to differentiate between malicious and honest administrators
  • Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
  • Authorization/Access Control relies on client-side information (e.g., hidden fields)
  • Web and application server processes run as root, Administrator, LOCALSYSTEM or other privileged accounts
  • Some web applications access the database via sa or other administrative account (or more privileges than required)
  • Some applications implement authorization controls by including a file or web control or code snippet on every page in the application
    <input type="text" name="fname" value="Derek">
    <input type="text" name="lname" value="Jeter">
    <input type="hidden" name="usertype" value="admin">
  • Some applications do not design roles with privilege levels. A “Read-Only” role on the application would access the database with all privileges. Design of an access control matrix would help in sorting out this issue.
  • Cross-site request forgery

Access Control Anti-Patterns

  • Hard-coded role checks in application code
  • 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
  • non-anonymous entry point DO NOT have an access control check
  • No authorization check at or near the beginning of code implementing sensitive activities
  • Adding multi-factor authentication can address privilege escalation

Hard Coded Roles

 if (user.isManager() ||
     user.isAdministrator() ||
     user.isEditor() ||
     user.isUser()) {
     //execute action
 }

Hard Codes Roles can create several issues including:

  • Making the policy of an application difficult to "prove" for audit or Q/A purposes
  • Causing new code to be pushed each time an access control policy needs to be changed.
  • They are fragile and easy to make mistakes

Order Specific Operations

Imagine the following parameters

 http://example.com/buy?action=chooseDataPackage
 http://example.com/buy?action=customizePackage
 http://example.com/buy?action=makePayment
 http://example.com/buy?action=downloadData

Can an attacker control the sequence?

Can an attacker abuse this with concurrency?

Never Depend on Untrusted Data

  • Never trust user data for access control decisions
  • 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

  • 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

Testing for Broken Access Control

  • Attempt to access administrative components or functions as an anonymous or regular user
    • 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

  • Implement role based access control to assign permissions to application users for vertical access control requirements
  • Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
  • 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
  • Perform access control reviews with respect to the access control matrix of the user interface / data access interface
  • Ensure that access control matrix adhere to segregation of duties – that the requestor cannot perform authorizations.


Java


if ( authenticated ) {

	request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;

}

.NET (C#)


if ( authenticated ) {

	Session[“AUTHLEVEL”] = X_USER;

}


PHP


if ( authenticated ) {

	$_SESSION[‘authlevel’] = X_USER; 	// X_USER is defined elsewhere as meaning, the user is authorized

}

Best Practices

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

Best Practice: Least Privilege

Assign only that level of privileges that are needed to perform the allocated activities.

For Example:

1. If on a banking application, a user has access to read account details, design an application id that has "Read-Only" privileges. Do not assign any privileges that might allow the user to transfer funds or change account details.

2. Map a "Read-Only" application id to a "Read-Only" database id and not a "admin" database id

3. If a user needs to access only one account do not sub-nest any further access that might give more privileges.

Best Practice: Segregation of Duties

While designing access controls ensure to have a demarkation between a maker and a checker. In simplistic terms, if a user requests for access to a particular resource, ensure that the user can not approve this request.

Best Practice: Access Control Reviews

Best Practice: Monitoring of access

1. user creation

2. user deletion

3. admin access

4. privilege changes

Best Practice: User Access management

1. User access provisioning:

2. User access revocation


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!

References

Authors and Primary Editors

Jim Manico - jim [at] owasp dot org
Fred Donovan - fred.donovan [at] owasp dot org
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org

Other Cheatsheets

OWASP Cheat Sheets Project Homepage