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 "URL Level Access Control Cheat Sheet"

From OWASP
Jump to: navigation, search
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}}

Revision as of 16:28, 30 January 2013

DRAFT CHEAT SHEET - WORK IN PROGRESS

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

Never Depend on Untrusted Data

Attacking Access Controls

Testing for Broken URL Level Access Control

Defenses Against URL Level Access Control Attacks

Best Practices

Best Practice: Code to the Activity

Best Practice: SOMETHING

Best Practice: SOMETHING ELSE

  • In Some Code
      (code*)here
  • In Controller
  (code*)here

Best Practice: Verifying policy server-side

SQL Integrated Access Control

Examples

Related Articles

OWASP Cheat Sheets Project Homepage