Access controls are one of the easiest areas of web application security to understand, although you must carefully apply a well-informed, thorough methodology
when implementing them.
First, you should avoid several obvious pitfalls. 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. Assume that users know every application URL and identifier, and ensure that the application’s access controls alone are suffi cient 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 cannot 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 then is transmitted via the client, do not rely on the retransmitted value without re validation.
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 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. If you force developers to explicitly code access control logic into every page, there can be no excuse for omissions.
For particularly sensitive functionality, such as administrative pages, you can further restrict access by IP address to ensure that only users from a specifi c network range can 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 fi les can be accessed indirectly by passing a filename to a dynamic server-side page that implements relevant access control logic. Second, direct access to static fi les can be controlled using HTTP authentication or other features of the application server to wrap the incoming request and check the resource’s permissions before access is granted.
Identifi ers specifying which resource a user wants 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 that 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 also mitigates the consequences of other possible attacks, such as session
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 step by step basis. They add code to individual pages in cases where some access control is required, and they often cut and paste 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 modifi cations 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
It makes maintainability more effi cient and reliable. Most changes need to be applied only once, to a single shared component, and do not need
to be cut and pasted to multiple locations.
It improves adaptability. Where new access control requirements arise, they can be easily refl ected within an existing API implemented by each application page.
It results in fewer mistakes and omissions than if access control code is implemented step by step throughout the application.