|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | = DRAFT CHEAT SHEET - WORK IN PROGRESS =
| + | {{taggedDocument| type=delete| comment=Tagged via fixme/delete.}} |
| − | =Introduction=
| |
| − | | |
| − | This article is focused on providing clear, simple, actionable guidance for providing Access Control security in your applications.
| |
| − | | |
| − | ==What is URL Level Access Control?==
| |
| − | | |
| − | | |
| − | =Attacks on URL Level Access Control=
| |
| − | | |
| − | =URL Level Access Control Issues=
| |
| − | | |
| − | =Access Control Anti-Patterns=
| |
| − | | |
| − | ==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= | |
| − | | |
| − | =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 =
| |
| − | | |
| − | {{Cheatsheet_Navigation}}
| |
