Penn Computing

Penn Computing

Computing Menu Computing A-Z
Computing Home Information Systems & Computing Penn


Tuesday, February 20, 2018

  New Resources
Security Logging Service
Travel Tips for Data Security
Free Security/Privacy Training Resources
Two-step verification
Combating Malware
Phishing Archive
Cloud Computing and Data Outsourcing
Best Practices for Applications with Confidential University Data
  Security "Greatest Hits"
Managing Passwords
E-mail Harassment & Forgery
Hoaxes, frauds & scams
Wireless Networking
  Best Practices
Secure desktop computing
Secure servers
Secure data deletion
Securing printers
Tips for safe computing
Computing policies
  More in-depth information for
Local support providers
System administrators
  Security initiatives
Critical Component compliance
Authentication & authorization
Penn Security & Privacy Assessment (SPIA)
Security Liaisons (Restricted Access)
Secure Share
Secure Space
Vulnerability Scanner
  Related links
Electronic privacy
Worms, trojans, backdoors

Top 10 Web Application Security Vulnerabilities

Based on OWASP Research

A2: Broken Access Control

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.


    The application user's identity should not be a value that is passed from the client as either a GET, POST or COOKIE variable.


    A malicious user can easily alter the user_id value in the URL to impersonate another user.


    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:

    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.

    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.


Information Systems and Computing
University of Pennsylvania
Comments & Questions

Penn Computing University of Pennsylvania
Information Systems and Computing, University of Pennsylvania