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

Difference between revisions of "Access Control Cheat Sheet"

From OWASP
Jump to: navigation, search
m (Point to the official site)
 
(92 intermediate revisions by 10 users not shown)
Line 1: Line 1:
=Introduction=
+
__NOTOC__
 +
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
  
This article is focused on providing clear, simple, actionable guidance for providing Access Control security in your applications.
+
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
  
==What is Access Control / Authorization?==
+
Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html Access Control Cheat Sheet] to see the latest version of the cheat sheet.
 
 
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)''' is commonly used to manage permissions within an application. Permissions are assigned to users in a many to many relationship.
 
 
 
'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an application.
 
 
 
'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be
 
 
 
=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)
 
 
    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
 
 
 
==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
 
 
 
==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
 
 
 
=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 a the lowest level!
 
 
 
=Authors and Primary Editors=
 
 
 
Jim Manico = jim [manico] dot net
 
 
 
Fred Donovan - fred.donovan [at] owasp dot org
 

Latest revision as of 13:54, 15 July 2019

Cheatsheets-header.jpg

The Cheat Sheet Series project has been moved to GitHub!

Please visit Access Control Cheat Sheet to see the latest version of the cheat sheet.