Difference between revisions of "Access Control Cheat Sheet"

From OWASP
Jump to: navigation, search
(Access Control Issues)
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
 
=Introduction=
 
=Introduction=
  
Line 9: Line 10:
 
Access Control is the method or mechanism of authorization to enfore that requests to a system resource or functionality should be granted.
 
Access Control is the method or mechanism of authorization to enfore that requests to a system resource or functionality should be granted.
  
'''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.
+
'''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.).  
  
'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an application.
+
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. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.
 +
*Roles are assigned based on organizational structure with emphasis on the organizational security policy
 +
*Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)  
 +
*Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
 +
*Roles are granted permissions based on the principle of least privilege.
 +
*Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
 +
*Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
 +
*Roles can be only be transferred or delegated using strict sign-offs and procedures.
 +
*Roles are managed centrally by a security administrator or project leader
 +
  
'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be
+
'''Discretioinary 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). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.
 +
*Data Owners can transfer ownership of information to other users
 +
*Data Owners can determine the type of access given to other users (read, write, copy, etc.)
 +
*Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user's access
 +
*Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminant copying by users ("cutting and pasting" of information)
 +
*Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
 +
*Access to information is determined based on authorizations to access control lists based on user identifier and group membership.
  
==Attacks on Access Control==
+
 
 +
'''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. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.
 +
*Only administrators, not data owners, make changes to a resource's security label.
 +
*All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
 +
*All users can read from a lower classification than the one they are granted (A "secret" user can read an unclassified document).
 +
*All users can write to a higher classification (A "secret" user can post information to a Top Secret resource).
 +
*All users are given read/write access to objects only of the same classification (a "secret" user can only read/write to a secret document).
 +
*Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user's credentials (driven by policy).
 +
*Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)
 +
 
 +
 
 +
=Attacks on Access Control=
  
 
Vertical Access Control Attacks - A standard user accessing administration functionality
 
Vertical Access Control Attacks - A standard user accessing administration functionality
Line 23: Line 50:
 
Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective
 
Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective
  
==Access Control Issues==
+
=Access Control Issues=
 +
*Many applications used the "All or Nothing" approach - Once authenticated, all users have equal privileges
  
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
  
Authorization Logic often relies on Security by Obscurity (STO) by assuming:
+
*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
*Users will not find unlinked or hidden paths or functionality
+
*Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
*Users will not find and tamper with "obscured" client side parameters (i.e. "hidden" form fields, cookies, etc.)
+
*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
 
 
Applications with multiple permission levels/roles often increases the possibility of conflicting permission sets resulting in unanticipated privileges
+
    <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'''
+
=Access Control Anti-Patterns=
  
 
*Hard-coded role checks in application code
 
*Hard-coded role checks in application code
Line 42: Line 79:
 
*Lack of addressing horizontal access control in a standardized way (if at all)
 
*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
 
*Access control logic that needs to be manually added to every endpoint in code
*Hard Coded Roles
+
*non-anonymous entry point DO NOT have an access control check
 +
*No authorization check at or near the beginning of code implementing sensitive activities
 +
 
 +
==Hard Coded Roles==
  
 
   if (user.isManager() ||
 
   if (user.isManager() ||
Line 53: Line 93:
 
'''Hard Codes Roles can create several issues including:'''
 
'''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
+
*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
 
Imagine the following parameters
Line 62: Line 106:
 
   http://example.com/buy?action=downloadData
 
   http://example.com/buy?action=downloadData
  
Can an attacker control the sequence?
+
'''Can an attacker control the sequence?'''
  
Can an attacker abuse this with concurency?
+
'''Can an attacker abuse this with concurency?'''
  
Never Depend on Untrusted Data
+
==Never Depend on Untrusted Data==
  
Never trust user data for access control decisions
+
*Never trust user data for access control decisions
Never make access control decisions in JavaScript
+
*Never make access control decisions in JavaScript
Never depend on the order of values sent from the client
+
*Never depend on the order of values sent from the client
Never make authorization decisions based solely on
+
*Never make authorization decisions based solely on
*hidden fields
+
**hidden fields
*cookie values
+
**cookie values
*form parameters
+
**form parameters
*URL parameters
+
**URL parameters
*anything else from the request
+
**anything else from the request
 
   
 
   
'''Access Control Issues'''
 
  
Many administrative interfaces require only a password for authentication
+
=Attacking Access Controls=
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)
+
+
    input type="text" name="fname" value="Derek"
+
    input type="text" name="lname" value="Jeter"
+
    input type="hidden" name="usertype" value="admin"
+
 
+
'''Attacking Access Controls'''
+
  
 
*Elevation of privileges
 
*Elevation of privileges
 
*Disclosure of confidential data - Compromising admin-level accounts often result in access to a user's confidential data
 
*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
 
*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
+
=Testing for Broken Access Control=
*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.  
+
*Attempt to access administrative components or functions as an anonymous or regular user
Ensure that adequate authentication is used and enforced
+
**Scour HTML source for “interesting” hidden form fields
For each user role, ensure that only the appropriate pages or components are accessible for that role.
+
**Test web accessible directory structure for names like admin, administrator, manager, etc (i.e. attempt to directly browse to “restricted” areas)
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.
+
*Determine how administrators are authenticated. Ensure that adequate authentication is used and enforced
If able to compromise administrator-level account, test for all other common web application vulnerabilities (poor input validation, privileged database access, etc)
+
*For each user role, ensure that only the appropriate pages or components are accessible for that role.
Defenses Against Access Control Attacks
+
*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)
  
Implement role based access control to assign permissions to application users for vertical access control requirements
+
=Defenses Against Access Control Attacks=
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
+
*Implement role based access control to assign permissions to application users for vertical access control requirements
Perform consistent authorization checking routines on all application pages
+
*Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis
+
*Avoid assigning permissions on a per-user 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)
+
*Perform consistent authorization checking routines on all application pages
Log all failed access authorization requests to a secure location for review by administrators
+
*Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis
Perform reviews of failed login attempts on a periodic 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)
Utilize the strengths and functionality provided by the SSO solution you chose
+
*Log all failed access authorization requests to a secure location for review by administrators
Best Practice: Code to the Activity
+
*Perform reviews of failed login attempts on a periodic basis
 +
*Utilize the strengths and functionality provided by the SSO solution you chose
 +
 
 +
'''Java'''
 +
 
 +
<pre>
 +
 
 +
if ( authenticated ) {
 +
 
 +
request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;
 +
 
 +
}
 +
 
 +
</pre>
 +
 
 +
'''.NET (C#)'''
 +
 
 +
<pre>
 +
 
 +
if ( authenticated ) {
 +
 
 +
Session[“AUTHLEVEL”] = X_USER;
 +
 
 +
}
 +
 
 +
</pre>
 +
 
 +
 
 +
'''PHP'''
 +
 
 +
<pre>
 +
 
 +
if ( authenticated ) {
 +
 
 +
$_SESSION[‘authlevel’] = X_USER; // X_USER is defined elsewhere as meaning, the user is authorized
 +
 
 +
}
 +
 
 +
</pre>
 +
 
 +
=Best Practices=
 +
 
 +
==Best Practice: Code to the Activity==
  
 
   if (AC.hasAccess(ARTICLE_EDIT)) {
 
   if (AC.hasAccess(ARTICLE_EDIT)) {
 
       //execute activity
 
       //execute activity
 
   }
 
   }
Code it once, never needs to change again
+
*Code it once, never needs to change again
Implies policy is persisted/centralized in some way
+
*Implies policy is persisted/centralized in some way
Avoid assigning permissions on a per-user basis
+
*Avoid assigning permissions on a per-user basis
Requires more design/work up front to get right
+
*Requires more design/work up front to get right
Best Practice: Centralized ACL Controler
+
  
Define a centralized access controller
+
==Best Practice: Centralized ACL Controller==
ACLService.isAuthorized(ACTION_CONSTANT)
+
 
ACLService.assertAuthorized(ACTION_CONSTANT)
+
*Define a centralized access controller
Access control decisions go through these simple API’s
+
      ACLService.isAuthorized(ACTION_CONSTANT)
Centralized logic to drive policy behavior and persistence
+
      ACLService.assertAuthorized(ACTION_CONSTANT)
May contain data-driven access control policy information
+
*Access control decisions go through these simple API’s
Policy language needs to support ability to express both access rights and prohibitions
+
*Centralized logic to drive policy behavior and persistence
Best Practice: Using a Centralized Access Controller
+
*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
  
      In Presentation Layer
 
 
       if (isAuthorized(VIEW_LOG_PANEL))
 
       if (isAuthorized(VIEW_LOG_PANEL))
 
       {
 
       {
 
           Here are the logs
 
           Here are the logs
 
           <%=getLogs();%/>
 
           <%=getLogs();%/>
       }
+
       }
      In Controller
+
 +
*In Controller
 +
 
 
       try (assertAuthorized(DELETE_USER))
 
       try (assertAuthorized(DELETE_USER))
 
       {
 
       {
Line 148: Line 227:
 
       }
 
       }
  
Best Practice:  
+
==Best Practice: Verifying policy server-side==
  
Verifying policy server-side
+
*Keep user identity verification in session
Keep user identity verification in session
+
*Load entitlements server side from trusted sources
Load entitlements server side from trusted sources
+
*Force authorization checks on ALL requests
Force authorization checks on ALL requests
+
**JS file, image, AJAX and FLASH requests as well!
*JS file, image, AJAX and FLASH requests as well!
+
**Force this check using a filter if possible
*Force this check using a filter if possible
+
SQL Integrated Access Control
+
  
Example Feature
+
=SQL Integrated Access Control=
 +
 
 +
'''Example Feature'''
  
 
     http://mail.example.com/viewMessage?msgid=2356342
 
     http://mail.example.com/viewMessage?msgid=2356342
  
This SQL would be vulnerable to tampering
+
'''This SQL would be vulnerable to tampering'''
  
 
   select * from messages where messageid = 2356342
 
   select * from messages where messageid = 2356342
  Ensure the owner is referenced in the query!
+
 
 +
'''Ensure the owner is referenced in the query!'''
 +
 
 
   select * from messages where messageid = 2356342 AND messages.message_owner =  
 
   select * from messages where messageid = 2356342 AND messages.message_owner =  
Access Control Positive Patterns
 
  
Code to the activity, not the role
+
=Access Control Positive Patterns=
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
+
*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.isAuthorized(EDIT_ORG, 142)
Line 187: Line 270:
 
     isAuthorized(user, EDIT_ORG, Organization.class, 14)
 
     isAuthorized(user, EDIT_ORG, Organization.class, 14)
 
 
Essentially checking if the user has the right role in the context of a specific object
+
*Essentially checking if the user has the right role in the context of a specific object
Centralize access control logic
+
*Centralize access control logic
Protecting data a the lowest level!
+
*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
 +
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org

Revision as of 11:18, 2 February 2013

Contents

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.

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.

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

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. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.

  • Roles are assigned based on organizational structure with emphasis on the organizational security policy
  • Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)
  • Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
  • Roles are granted permissions based on the principle of least privilege.
  • Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
  • Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
  • Roles can be only be transferred or delegated using strict sign-offs and procedures.
  • Roles are managed centrally by a security administrator or project leader


Discretioinary 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). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.

  • Data Owners can transfer ownership of information to other users
  • Data Owners can determine the type of access given to other users (read, write, copy, etc.)
  • Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user's access
  • Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminant copying by users ("cutting and pasting" of information)
  • Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
  • Access to information is determined based on authorizations to access control lists based on user identifier and group membership.


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. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.

  • Only administrators, not data owners, make changes to a resource's security label.
  • All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
  • All users can read from a lower classification than the one they are granted (A "secret" user can read an unclassified document).
  • All users can write to a higher classification (A "secret" user can post information to a Top Secret resource).
  • All users are given read/write access to objects only of the same classification (a "secret" user can only read/write to a secret document).
  • Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user's credentials (driven by policy).
  • Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)


Attacks on Access Control

Vertical Access Control Attacks - A standard user accessing administration functionality

Horizontal Access Control attacks - Same role, but accessing another user's private data

Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective

Access Control Issues

  • 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">

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

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 concurency?

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

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

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

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets

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