|
|
| Line 14: |
Line 14: |
| | | | |
| | ==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 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= | | =Attacking Access Controls= |
| | | | |
| − | *Elevation of privileges
| + | =Testing for Broken URL Level Access Control= |
| − | *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=
| + | =Defenses Against URL Level Access Control Attacks= |
| − | | |
| − | *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 Practices= |
| Line 71: |
Line 27: |
| | ==Best Practice: Code to the Activity== | | ==Best Practice: Code to the Activity== |
| | | | |
| − | if (AC.hasAccess(ARTICLE_EDIT)) {
| + | ==Best Practice: SOMETHING== |
| − | //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== | + | ==Best Practice: SOMETHING ELSE== |
| | | | |
| − | *Define a centralized access controller | + | *In Some Code |
| − | 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==
| + | (code*)here |
| − | | |
| − | *In Presentation Layer
| |
| − | | |
| − | if (isAuthorized(VIEW_LOG_PANEL)) | |
| − | {
| |
| − | Here are the logs
| |
| − | <%=getLogs();%/>
| |
| − | }
| |
| | | | |
| | *In Controller | | *In Controller |
| | | | |
| − | try (assertAuthorized(DELETE_USER))
| + | (code*)here |
| − | {
| |
| − | deleteUser();
| |
| − | }
| |
| | | | |
| | ==Best Practice: Verifying policy server-side== | | ==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''' | + | '''Examples''' |
| − | | |
| − | 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 = | | = Related Articles = |
| | | | |
| | {{Cheatsheet_Navigation}} | | {{Cheatsheet_Navigation}} |
