![]()
Chapter 1
Access Control
One of the most basic forms of protection that any web application must utilize is the enforcement of an authentication and authorization policy.
Authentication deals with identifying users to the application; in APEX this is provided by a number of default authentication schemes and can be extended using a custom authentication scheme. Authorization is the process of assessing whether the authenticated user is privileged to access certain data or perform a particular action.
The term access control covers both aspects, and access-control vulnerabilities arise when either authentication can be abused to allow access to an application without valid credentials, or when authorization is incorrectly applied, allowing valid users to access parts of the application for which they should not have privileges.
One of the great things about APEX is the capability to apply authorization schemes to a wide range of components. At a simple level, pages within an APEX application can be protected by your authorization scheme to prevent access to certain sets of users. The applicability of authorization schemes is a lot more granular: reports, buttons, and processes can all also be protected. Users with different privileges can then only view or access specific components on a page. While APEX provides a great access control model, there are some common mistakes that are made where data and functionality do not get protected as you might expect. This chapter will guide you through the various access control features and show how they can be used securely in your applications.
THE PROBLEM
When authentication or authorization is not applied correctly, an unauthenticated user with no access to the application may be able to view and interact with the data it is intended to protect. Valid (but malicious) users of the application may also be able to invoke operations that should be restricted to a limited subset of users.
In our experience performing security assessments of APEX applications, we can say that although APEX provides fantastic flexibility and granularity with authorization, in many cases such protection is not defined or applied correctly. As an APEX application grows and matures, we often see newer pages and components that do not have the protection they require. In one (extreme!) case, we analyzed an application where the Create Admin User page was not protected, and could be accessed by any authenticated user of the application.
THE SOLUTION
By ensuring that the authentication scheme used by your APEX application is robust and conforms to best practice, you can be confident that only legitimate users of the application should have access. Of course, other attacks against an APEX application can allow those malicious attackers to get in even when authentication is defined correctly, but these attacks (such as using Cross-Site Scripting to steal a valid user’s credentials, or SQL Injection to access arbitrary data within the database) can be mitigated in other ways and are discussed later in this book.
Authorization should be applied to those areas within an application that need to be protected from subsets of valid authenticated users. Only very simple applications are designed with one generic user level; most have at least some notion of “role” with base-level users, and administrative functionality for a specific group of users.
We’re not going to cover designing and documenting an application’s access-control model, as this is very dependent on the specific requirements of the application. However, this is a crucial step when developing any system. Such requirements should be captured when the system is planned, and then once implemented, the access-control structure can be compared with the initial intentions.
Instead, we present some common access-control mishaps that we’ve observed across a number of APEX applications, and discuss how the simple addition of access-control settings can secure the APEX application.
AUTHENTICATION
The first stage is to define a reasonable authentication scheme for the application. In general, any authentication scheme should be capable of identifying users based on some description of who they are (their username) and a secret that nobody except the user should know (such as a password).
Depending on the requirements of the APEX application, you define authentication using one of the built-in methods or via a custom scheme, as shown in Figure 1-1.
No rules exist for which of these schemes to use or avoid (although choosing Open Door Credentials would require confidence that the data and operations of the application were truly intended for everybody).
When authenticating users based on the traditional credentials of username and password, here is some “best practice” guidance that you should consider:
- Account lockout: If a user attempts authentication with an invalid password a number of times, consider rejecting future access for a certain period (the chosen threshold and timeout depends on the sensitivity of the application and the corporate security policy).
- Password complexity: Users invariably choose the simplest password they can, so an application should enforce a level of complexity so attackers cannot guess valid user credentials (again, the chosen policy depends on the application).
- Password reset: Where an application allows users to reset their password if they forget, it should either require some additional confirmation or send a reset link with a unique token to their configured e-mail address. The application should not allow a reset based on some publicly available information (for example, birth date or mother’s maiden name), and should never e-mail users their actual password.
- Password storage: The application should not store user credentials in clear text, but instead should store passwords that are cryptographically “hashed” and preferably “salted” with a unique value. This limits the damage of the worst-case-scenario of your account information being compromised, because an attacker would still not be able to authenticate as other users without “cracking” the password hashes. Storing passwords that are encrypted, rather than hashed, is not considered good practice because they can be decrypted should the key be discovered.
With authentication defined and adhering to these guidelines and applied to an APEX application, any non-public page should be protected so that only legitimate users have access. This is the first part of the story of access control; the next stage is applying authorization to provide more granular control over the functionality available to users.
Application Authentication
You can define the authentication scheme in the Security section of an APEX application’s properties, as shown in Figure 1-2. This scheme is used whenever a page that requires authentication is requested by a user who is not logged in. It is possible to specify No Authentication, effectively making all pages publicly accessible; needless to say, you should not use this without very careful consideration about the data and features within an application.
Page Authentication
You can apply authentication to pages within an APEX application via the Security section of the page properties, as shown in Figure 1-3.
This setting dictates simply whether a user needs to be authenticated to access the page. If a page doesn’t require authentication, it is considered a public page.
Ge...
