A2.1 Description
Access control, sometimes called authorization, is
the means by which a web application grants access to specified
content and functions to some users and not others. Access control
governs what "authorized" users are allowed to do. Access control
sounds like a simple problem but is insidiously difficult to
implement correctly. A web application"s access control model is
closely tied to the content and functions that the site provides. In
addition, the users may fall into a number of groups or roles, with
different abilities or privileges.
Typically, authentication must precede
authorization. Authentication verifies the identity of a user.
Authorization is then used to determine what that user is allowed to
access. To ensure proper access control, a web application must
ensure both that it has proper authorization checks, and that it is
using reliable and secure authentication that can distinguish
privileged users from others, including random strangers on the
Internet.
Developers frequently underestimate the difficulty
of implementing a reliable access control mechanism. Many access
control schemes were not deliberately designed, but have simply
evolved along with the web site. In these cases, access control rules
are inserted in various locations all over the code. As the site
nears deployment, the ad hoc collection of rules becomes so unwieldy
that it is almost impossible to understand.
Many of these flawed access control schemes are
not difficult to discover and exploit. Frequently, all that is
required is to craft a request for functions or content that should
not be granted. Once a flaw is discovered, the consequences of a
flawed access control scheme can be devastating. In addition to
viewing unauthorized content, an attacker might be able to change or
delete content, perform unauthorized functions, or even take over
site administration.
One particularly dangerous type of access control
vulnerability arises from Web-accessible administrative interfaces.
Such features are frequently used to allow site administrators to
efficiently manage users, data, and content on their site. In many
instances, sites support a variety of administrative roles to allow
finer granularity of site administration. Due to their power, these
interfaces are frequently prime targets for attack by both outsiders
and insiders.
A2.2 Environments
Affected
All known web servers, application servers, and
web application environments are susceptible to at least some of
these issues. Even if a site is completely static, if it is not
configured properly, hackers could gain access to sensitive files and
deface the site, or perform other mischief.
Some of the more commonly used mechanisms related
to access control in the Penn environment include:
PennKey:
The preferred authentication method for Penn, it should be used
whenever feasible. However, it is vitally important that
applications always use encrypted channels for transmitting PennKey
credentials, and be hardened against compromising the Pennkey password.
Non-Penn users can be assigned a permanent or temporary PennKey if necessary.
UPHS: For
Medview NT Authorization is used.
Websec:
Applications using Websec should have a logout mechanism to
destroy tokens so someone can't take a user's token and login
to their session again. This is critical on public kiosk machines.
Gold card authentication: Used by the Library for some users, such as those
from CHOP.
A2.3 Examples and References
A2.4 How to Determine If You Are Vulnerable
Virtually all sites have some access control
requirements. Therefore, an access control policy should be clearly
documented. Also, the design documentation should capture an approach
for enforcing this policy. If this documentation does not exist, then
a site is likely to be vulnerable.
The code that implements the access control policy
should be checked. Such code should be well structured, modular, and
most likely centralized. A detailed code review should be performed
to validate the correctness of the access control implementation. In
addition, penetration testing can be quite useful in determining if
there are problems in the access control scheme.
Find out how your website is administered. You
want to discover how changes are made to webpages, where they are
tested, and how they are transported to the production server. If
administrators can make changes remotely, you want to know how those
communications channels are protected. Carefully review each
interface to make sure that only authorized administrators are
allowed access. Also, if there are different types or groupings of
data that can be accessed through the interface, make sure that only
authorized data can be accessed as well. If such interfaces employ
external commands, review the use of such commands to make sure they
are not subject to any of the command injection flaws described in
this paper.
A2.5 How to Protect Yourself
The most important step is to think through an
application's access control requirements and capture it in a web
application security policy. We strongly recommend the use of an
access control matrix to define the access control rules. Without
documenting the security policy, there is no definition of what it
means to be secure for that site. The policy should document what
types of users can access the system, and what functions and content
each of these types of users should be allowed to access. The access
control mechanism should be extensively tested to be sure that there
is no way to bypass it. This testing requires a variety of accounts
and extensive attempts to access unauthorized content or functions.
Some specific access control issues include:
Insecure
IDs - Most web sites use some form of identifier (ID), key, or
index as a way to reference users, roles, content, objects, or
functions. If an attacker can guess these IDs, and the supplied
values are not validated to ensure they are authorized for the
current user, the attacker can exercise the access control scheme
freely to see what they can access. Web applications should not rely
on the secrecy of any IDs for protection.
Example:
The application user's identity should not be a value that is passed
from the client as either a GET, POST or COOKIE variable.
Bad:
http://dept.upenn.edu/bad_app?user_id=3
A malicious user can easily alter the user_id value in the URL to impersonate
another user.
Good:
http://dept.upenn.edu/good_app?token=36423c633d685645232ac3ee7c0d77bc
The application converts the token (a hard to guess value) via a database
lookup to a user_id. The token was assigned when the user logged in
and should expire at some point. The token should be generated using
some random data so it cannot be duplicated easily.
Forced
Browsing Past Access Control Checks - Many sites require users to
pass certain checks before being granted access to certain URLs that
are typically "deeper" down in the site. These checks must not
be bypassable by a user that simply skips over the page with the
security check.
In other words, do not use navigation options
as a substitute for authorization checks. Just because a user cannot
click to get to a page doesn't mean that page is protected. Your
application should do authorization checks on EVERY page it
generates.
Example 1:
A course instructor wants to distribute homework answers to the course
graders via a web application. Graders login to the site and are
presented with a list of homework assignments. The grader clicks on
the assignment and gets redirected to an HTML page with the answers
for that assignment:
http://school.upenn.edu/course_site/graders/secret/answers.html
Even though there is no link on the course web page to the "secret"
answers page, a user can bypass the application login and go directly
to the URL the instructor is trying to protect.
Example 2:
An application is designed to allow various departments to track their
students. Each department should only be allowed to view and update
their own students. The application generates an "Edit"
page which allows a user to edit a student's data.
http://school.upenn.edu/app/edit_student?student_id=34231
Before displaying any data, the edit_student page needs to look up the
department of the student and verify that the current user belongs to
that department.
The application will also have a corresponding page which saves the
user's edits to the database. That page must perform the same
security checks as the edit page.
Path Traversal - This attack involves providing relative path
information (e.g., "../../target_dir/target_file") as part of a
request for information. Such attacks try to access files that are
normally not directly accessible by anyone, or would otherwise be
denied if requested directly. Such attacks can be submitted in URLs
as well as any other input that ultimately accesses a file (i.e.,
system calls and shell commands).
-
Limit file permissions on web files - Many web and application servers rely on access
control lists provided by the file system of the underlying
platform. Even if almost all data is stored on backend servers,
there are always files stored locally on the web and application
server that should not be publicly accessible, particularly
configuration files, default files, and scripts that are installed
on most web and application servers. Only files that are
specifically intended to be presented to web users should be marked
as readable by the web application using the OS's permissions
mechanism. Most directories should not be readable, and very few
files, if any, should be marked executable.
Client Side
Caching - Many users access web applications from shared computers
located in libraries, schools, airports, and other public access
points. Browsers frequently cache web pages that can be accessed by
attackers to gain access to otherwise inaccessible parts of sites.
Developers should use multiple mechanisms, including HTTP headers
and meta tags, to be sure that pages containing sensitive
information are not cached by user"s browsers.
The following http headers are useful for specifying client caching behavior:
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
New browsers support even more caching control using these headers:
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Other tips for securing access control:
Check authorization on every page of the application.
Note that users can supply their own URLs, including unexpected ones. Check
them.
Do not inadvertently become a proxy for services behind a firewall.
Only allow short amounts of time for token sessions.
Destroy tokens on the server side on user logout.
Remove all demo/debug code before going live with an application.
Change/verify defaults in third party code or applications. E.g., be default, the Mysql root account does not require a password when connecting from the local host.
Do not use higher
privileges than are necessary. Web servers should run using a
low-privilege account. Web applications should access database resources using an account with minimal privileges required by the application.
Limit file permissions on web files.
-
Do not create session id's based solely on user input. Force a "sufficiently random" session id. Avoid any guessable id's such as a time stamp or other sequential formula.
Do not use timestamps as a token. Timestamps can be used in generating a token, but timestamps alone are easily guessable and may not be unique. Timestamps should be used for expiring tokens.
Verify
the session. Do not trust IP addresses. DSL and AOL users may
have their IP addresses change at unpredictable times. Dial-up
users are also likely to have an odd IP address.
Do not embed database or other IDs or passwords in application code.
There are some application layer security
components that can assist in the proper enforcement of some aspects
of your access control scheme. As with input validation, to be
effective the component must be configured with a strict definition
of what access requests are valid for your site. When using such a
component, you must be careful to understand exactly what access
control assistance the component can provide for you given your
site's security policy, and what part of your access control policy
that the component cannot deal with, and therefore must be properly
dealt with in your own custom code.
For server
administrative functions such as creating system accounts, modifying databases, etc), the primary recommendation is to never
allow administrator access through a web interface if at
all possible. Given the power of administrator interfaces, most
organizations should not accept the risk of making these interfaces
available to outside attack. If remote administrator access is
absolutely required, this can be accomplished without a web interface.
For instance, VPN technology could be used
to provide an outside administrator access to the internal company
(or site) network from which an administrator could then access the
site through a protected backend connection.
