Introductoin:
This article is focused on providing clear, simple, actionable guidance for
providing Access Control security in your applications.
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) In Role-Based Access Control
(RBAC), access decisions are based on an individual's roles and
responsibilities within the organization or user base. The process of defining
roles is usually based on analyzing the fundamental goals and structure of an
organization and is usually linked to the security policy. For instance, in a
medical organization, the different roles of users may include those such as
doctor, nurse, attendant, nurse, patients, etc. Obviously, these members
require different levels of access in order to perform their functions, but
also the types of web transactions and their allowed context vary greatly
depending on the security policy and any relevant regulations (HIPAA,
Gramm-Leach-Bliley, etc.).
An RBAC access control framework should provide web application security
administrators with the ability to determine who can perform what actions,
when, from where, in what order, and in some cases under what relational
circumstances. http://csrc.nist.gov/rbac/ provides some
great resources for RBAC implementation. The following aspects exhibit RBAC
attributes to an access control model.
- Roles are
assigned based on organizational structure with emphasis on the
organizational security policy
- Roles are
assigned by the administrator based on relative relationships within the
organization or user base. For instance, a manager would have certain
authorized transactions over his employees. An administrator would have
certain authorized transactions over his specific realm of duties (backup,
account creation, etc.)
- Each role
is designated a profile that includes all authorized commands,
transactions, and allowable information access.
- Roles are
granted permissions based on the principle of least privilege.
- Roles are
determined with a separation of duties in mind so that a developer Role
should not overlap a QA tester Role.
- Roles are
activated statically and dynamically as appropriate to certain relational
triggers (help desk queue, security alert, initiation of a new project,
etc.)
- Roles can
be only be transferred or delegated using strict sign-offs and procedures.
- Roles are managed centrally by a security administrator or project
leader
Discretioinary Access Control (DAC) Discretionary Access Control (DAC) is a means of
restricting access to information based on the identity of users and/or membership in certain
groups. Access decisions are typically based on the authorizations granted to a
user based on the credentials he presented at the time of authentication (user
name, password, hardware/software token, etc.). In most typical DAC models, the
owner of information or any resource is able to change its permissions at his
discretion (thus the name). DAC has the drawback of the administrators not
being able to centrally manage these permissions on files/information stored on
the web server. A DAC access control model often exhibits one or more of the
following attributes.
- Data
Owners can transfer ownership of information to other users
- Data
Owners can determine the type of access given to other users (read, write,
copy, etc.)
- Repetitive
authorization failures to access the same resource or object generates an
alarm and/or restricts the user's access
- Special
add-on or plug-in software required to apply to an HTTP client to prevent
indiscriminant copying by users ("cutting and pasting" of
information)
- Users who
do not have access to information should not be able to determine its
characteristics (file size, file name, directory path, etc.)
- Access to
information is determined based on authorizations to access control lists
based on user identifier and group membership.
Mandatory Access Control (MAC) Mandatory Access Control (MAC) ensures
that the enforcement of organizational security policy does not rely on
voluntary web application user compliance. MAC secures information by assigning
sensitivity labels on information and comparing this to the level of
sensitivity a user is operating at. In general, MAC access control mechanisms
are more secure than DAC yet have trade offs in performance and convenience to
users. MAC mechanisms assign a security level to all information, assign a
security clearance to each user, and ensure that all users only have access to
that data for which they have a clearance. MAC is usually appropriate for
extremely secure systems including multilevel secure military applications or
mission critical data applications. A MAC access control model often exhibits
one or more of the following attributes.
- Only
administrators, not data owners, make changes to a resource's security
label.
- All data
is assigned security level that reflects its relative sensitivity,
confidentiality, and protection value.
- All users
can read from a lower classification than the one they are granted (A
"secret" user can read an unclassified document).
- All users
can write to a higher classification (A "secret" user can post
information to a Top Secret resource).
- All users
are given read/write access to objects only of the same classification (a
"secret" user can only read/write to a secret document).
- Access is
authorized or restricted to objects based on the time of day depending on
the labeling on the resource and the user's credentials (driven by
policy).
- Access is
authorized or restricted to objects based on the security characteristics
of the HTTP client (e.g. SSL bit length, version information, originating
IP address or domain, etc.)
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
- 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)
- Web and
application server processes run as root, Administrator, LOCALSYSTEM or
other privileged accounts
- Some web
applications access the database via sa or other administrative account
(or more privileges than required)
- Some
applications implement authorization controls by including a file or web control
or code snippet on every page in the application
<input type="text"
name="fname" value="Derek">
<input type="text"
name="lname" value="Jeter">
<input type="hidden"
name="usertype" value="admin">
- 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
- non-anonymous
entry point DO NOT have an access control check
- No
authorization check at or near the beginning of code implementing
sensitive activities
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
Imagine the following parameters
Can an attacker control the sequence?
Can an attacker abuse this with concurency?
- 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
- 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
- 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)
- 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
Java
if (
authenticated ) {
request.getSession(true).setValue(“AUTHLEVEL”)
= X_USER;
}
.NET (C#)
if (
authenticated ) {
Session[“AUTHLEVEL”] = X_USER;
}
PHP
if ( authenticated
) {
$_SESSION[‘authlevel’] = X_USER; // X_USER is defined elsewhere as meaning,
the user is authorized
}
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
- 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
if (isAuthorized(VIEW_LOG_PANEL))
{
Here are the logs
<%=getLogs();%/>
}
try (assertAuthorized(DELETE_USER))
{
deleteUser();
}
- 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
Example Feature
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 =
- 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 / 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!
