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"
(→Access Control Issues) |
|||
Line 15: | Line 15: | ||
'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be | '''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 | Vertical Access Control Attacks - A standard user accessing administration functionality | ||
Line 23: | Line 23: | ||
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= | |
+ | *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 | |
− | Authorization Logic often relies on Security by Obscurity (STO) by assuming: | + | **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 | *Hard-coded role checks in application code | ||
Line 42: | Line 49: | ||
*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== | ||
if (user.isManager() || | if (user.isManager() || | ||
Line 53: | Line 61: | ||
'''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 | + | *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 | Imagine the following parameters | ||
Line 62: | Line 74: | ||
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 |
− | |||
− | + | =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= | |
− | |||
− | |||
− | 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. |
− | + | *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 | ||
+ | |||
+ | =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 |
− | |||
− | Define a centralized access controller | + | ==Best Practice: Centralized ACL Controller== |
+ | |||
+ | *Define a centralized access controller | ||
ACLService.isAuthorized(ACTION_CONSTANT) | ACLService.isAuthorized(ACTION_CONSTANT) | ||
ACLService.assertAuthorized(ACTION_CONSTANT) | ACLService.assertAuthorized(ACTION_CONSTANT) | ||
− | Access control decisions go through these simple API’s | + | *Access control decisions go through these simple API’s |
− | Centralized logic to drive policy behavior and persistence | + | *Centralized logic to drive policy behavior and persistence |
− | May contain data-driven access control policy information | + | *May contain data-driven access control policy information |
− | Policy language needs to support ability to express both access rights and prohibitions | + | *Policy language needs to support ability to express both access rights and prohibitions |
− | Best Practice: Using a Centralized Access Controller | + | |
+ | ==Best Practice: Using a Centralized Access Controller== | ||
+ | |||
+ | *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 | ||
+ | |||
try (assertAuthorized(DELETE_USER)) | try (assertAuthorized(DELETE_USER)) | ||
{ | { | ||
Line 148: | Line 158: | ||
} | } | ||
− | Best Practice: | + | ==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= | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | SQL Integrated Access Control | ||
− | Example Feature | + | '''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!''' | ||
+ | |||
select * from messages where messageid = 2356342 AND messages.message_owner = | select * from messages where messageid = 2356342 AND messages.message_owner = | ||
− | |||
− | Code to the activity, not the role | + | =Access Control Positive Patterns= |
− | Centralize access control logic | + | |
− | Design access control as a filter | + | *Code to the activity, not the role |
− | Deny by default, fail securely | + | *Centralize access control logic |
− | Build centralized access control mechanism | + | *Design access control as a filter |
− | Apply same core logic to presentation and server-side access control decisions | + | *Deny by default, fail securely |
− | Determine access control through Server-side trusted data | + | *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 / Horizontal Access Control API examples | + | =Data Contextual Access Control= |
+ | |||
+ | '''Data Contextual / Horizontal Access Control API examples''' | ||
ACLService.isAuthorized(EDIT_ORG, 142) | ACLService.isAuthorized(EDIT_ORG, 142) | ||
Line 187: | Line 201: | ||
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 a the lowest level! |
+ | |||
+ | =Authors and Primary Editors= | ||
+ | |||
+ | Jim Manico = jim [manico] dot net | ||
+ | |||
+ | Fred Donovan - fred.donovan [at] owasp dot org |
Revision as of 17:30, 11 March 2012
- 1 Introduction
- 2 Attacks on Access Control
- 3 Access Control Issues
- 4 Access Control Anti-Patterns
- 5 Attacking Access Controls
- 6 Testing for Broken Access Control
- 7 Defenses Against Access Control Attacks
- 8 Best Practices
- 9 SQL Integrated Access Control
- 10 Access Control Positive Patterns
- 11 Data Contextual Access Control
- 12 Authors and Primary Editors
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) 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