URL Level Access Control Cheat Sheet

Introduction

This article is focused on providing clear, simple, actionable guidance for providing Access Control security in your applications.

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 = 

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

• OWASP Cheat Sheet Series