S 4.402 Access control for web applications

Initiation responsibility: Head of Specialised Department, Persons responsible for individual applications

Implementation responsibility: Administrator, Developer

The authorisation component of a web application must ensure that the users may only perform such activities they have the proper authorisations for. Here, rights can be assigned on the basis of user roles.

The authorisation component should take into consideration all managed resources of a web application. This includes, e.g.

If possible, access control must be implemented on all levels of a web application (e.g. through the web application, the application server, the web server, and the operating system). Hence, the safeguards S 4.94 Protection of web server files and S 5.168 Secure connection of background systems to web applications should be taken into consideration for access control of data on the web server and in background systems, along with access control at a web application level.

The following points should be taken into consideration for secure access control at a web application level:

General aspects

Authorisations must be assigned restrictively and according to the minimum principle. The users of the web application should therefore only have such rights absolutely required for performing their tasks.

Every access to protected content and functions should be controlled before being implemented. This is also applicable if the same user repeatedly accesses a protected resource. Even automated client requests with the help of web technologies (e.g. Ajax) should be deemed independent requests and controlled accordingly.

Requirements for the authorisation component

Normally, web applications are used with the help of a generic client not controlled by the web application. This way, an attacker can generally manipulate the request manually and bypass security mechanisms implemented on the client. For this reason, the authorisation must be implemented on the server using a trustworthy IT system.

The authorisation routines should be implemented in a centralised manner at one location and not distributed within the program code of the web application. This way, the code of the authorisation component is separated from the business logic of the web application and redundant and error-prone implementation is avoided. If possible, functions of already existing frameworks should be used when developing the authorisation component.

If errors occur during access control (e.g. because insufficient information is used for authorisation), accesses must be denied. In the event of an error, no requested resources must be transmitted or no functions must be executed in an uncontrolled manner.

Control of all resources involved in an activity

A user must not be able to implement an activity on a resource he/she does not have sufficient rights for. For example, if an authenticated user changes the URL parameter for the assignment to a bank account, he/she must not gain access to a third party bank account this way. If the rights for performing the activity are reviewed, the review should include all resources involved in the activity.

This also refers to the implementation and configuration of the search function of a web application. It should be ensured that access-protected resources are not presented as a search result to an unauthorised user. Therefore, it should be checked whether the user has the required rights in order to view the search results before the search results are displayed, for example.

Access control for URL requests and object references

Websites and other resources of the web application are normally identified and called via the URL. In this, a user normally calls websites and functions of the web application with the help of the displayed links on an already displayed website of the application.

If resources of the web application are to be protected, it is not sufficient to remove the link to the resource from the displayed websites (e.g. a link to the administration site), but direct access of the resource using the URL must be prohibited as well.

The sites of web applications are frequently created dynamically on the basis of references to objects (e.g. the ID of the database entry). If the users of the web application transfer these references (e.g. as a parameter in the URL), the parameter and therefore the reference may be changed randomly by a user.

Since these are not direct references (e.g. to files), but indirect references (references to objects), access control should be performed on the basis of the reference values (e.g. IDs). Furthermore, additional access control for the requested objects in the background systems should be performed, if possible. For example, this may be implemented by forwarding the user authentication to the background systems (see also S 5.168 Secure connection of background systems to web applications).

Restrictive file system authorisations for the upload function

As a matter of principle, access to files by the users of the web application should be limited by restrictive file system authorisations (see S 4.398 Secure configuration of web applications).

If the web application provides a file upload functionality, only the owner should dispose of the file system authorisation for accessing the created files upon successful upload. In another step, access to the files can be approved expressly for other users. As a matter of principle, it must be ensured that the execution rights are withdrawn from the uploaded files so that an attacker is not able to execute malicious code in this way (see also S 4.399 Controlled integration of data and content in web applications).

Protection of temporary files

For dynamically created websites, temporary data (e.g. analysis graphs, reports) are frequently generated. If this is data worthy of protection, this data should not be cached in the file system, if possible. The data should be delivered directly to the user instead. If data worthy of protection must be stored in temporary files, the following points must be taken into consideration:

Review questions:

© Federal Office for Information Security. All rights reserved.