Securing Access Controls
Access controls are one of the easiest areas of web application security to understand, although a well-informed, thorough methodology must be carefully applied when implementing them.
First, there are several obvious pitfalls to avoid. These usually arise from ignorance about the essential requirements of effective access control or flawed assumptions about the kinds of requests that users will make and against which the application needs to defend itself:
■ Do not rely on users’ ignorance of application URLs or the identifiers used to specify application resources, such as account numbers and document IDs. Explicitly assume that users know every application URL and identifier, and ensure that the application’s access controls alone are sufficient to prevent unauthorized access.
■ Do not trust any user-submitted parameters to signify access rights (such as admin=true ).
■ Do not assume that users will access application pages in the intended sequence. Do not assume that because users cannot access the Edit Users page, they will not be able to reach the Edit User X page that is linked from it.
■ Do not trust the user not to tamper with any data that is transmitted via the client. If some user-submitted data has been validated and is then transmitted via the client, do not rely upon the retransmitted value without revalidation.
The following represents a best-practice approach to implementing effective access controls within web applications:
■ Explicitly evaluate and document the access control requirements for every unit of application functionality. This needs to include both who can legitimately use the function and what resources individual users may access via the function.
■ Drive all access control decisions from the user’s session.
■ Use a central application component to check access controls.
■ Process every single client request via this component, to validate that the user making the request is permitted to access the functionality and resources being requested.
■ Use programmatic techniques to ensure that there are no exceptions to the previous point. An effective approach is to mandate that every application page must implement an interface that is queried by the central access control mechanism. By forcing developers to explicitly code access control logic into every page, there can be no excuse for comissions.
■ For particularly sensitive functionality, such as administrative pages, you can further restrict access by IP address, to ensure that only users from a specific network range are able to access the functionality, regardless of their login status.
■ If static content needs to be protected, there are two methods of providing access control. First, static files can be accessed indirectly by passing a file name to a dynamic server-side page which implements relevant access control logic. Second, direct access to static files can be controlled using HTTP authentication or other features of the application server to wrap the incoming request and check the permissions for the resource before granting access.
■ Identifiers specifying which resource a user wishes to access are vulnerable to tampering whenever they are transmitted via the client. The server should trust only the integrity of server-side data. Any time these identifiers are transmitted via the client, they need to be revalidated to ensure the user is authorized to access the requested resource.
■ For security-critical application functions such as the creation of a new bill payee in a banking application, consider implementing per transaction reauthentication and dual authorization to provide additional assurance that the function is not being used by an unauthorized party. This will also mitigate the consequences of other possible attacks, such as session hijacking.
■ Log every event where sensitive data is accessed or a sensitive action is performed. These logs will enable potential access control breaches to be detected and investigated.
Web application developers often implement access control functions on a piecemeal basis, adding code to individual pages in cases where they register that some access control is required, and often cutting and pasting the same code between pages to implement similar requirements. This approach carries an inherent risk of defects in the resulting access control mechanism: many cases are overlooked where controls are required, controls designed for one area may not operate in the intended way in another area, and modifications made elsewhere within the application may break existing controls by violating assumptions made by them.
In contrast to this approach, the previously described method of using a central application component to enforce access controls has many benefits:
■ It increases the clarity of access controls within the application, enabling different developers to quickly understand the controls implemented by others.
■ It makes maintainability more efficient and reliable. Most changes will only need to be applied once, to a single shared component, and will not need to be cut and pasted to multiple locations.
■ It improves adaptability. Where new access control requirements arise, these can be easily reflected within an existing API implemented by each application page.
■ It results in fewer mistakes and omissions than if access control code is implemented piecemeal throughout the application.
NEXT is..A Multi-Layered Privilege Model………..,,.,.,.,.,.,.,..,
