S 4.398 Secure configuration of web applications

Initiation responsibility: Head of IT

Implementation responsibility: Administrator, Developer

If a web application is configured insufficiently, an attacker may overcome the existing security safeguards. Therefore, it must be ensured that the web application is configured in such a way that accesses are only possible using the designed, secured communication paths. Access to resources and functions not required must therefore be restricted.

The following items should be taken into consideration when configuring the web application:

Deactivation of unnecessary HTTP methods

According to the HTTP standard, there are different methods for accessing a web application (e.g. GET, POST, PUT, DELETE, or TRACE). Normally, a web application only requires a very limited number of these HTTP methods, however (e.g. GET and POST).

Furthermore, a web application may react differently to a request depending on the HTTP method used. For example, if the input data is only filtered in case of a GET or POST request, this security feature may be bypassed by calling a HTTP method that was not designed.

Some HTTP methods (e.g. PUT) offer access to security-critical functionality (e.g. uploading any files) and allow for bypassing restrictions of the web application this way (e.g. the file type check within the framework of an upload feature).

For these reasons, HTTP methods not required should be deactivated and not processed by the web application. This also holds true for fictitious HTTP methods not defined within the corresponding RPC 2616 standard. Even if the HTTP methods were already disabled in the web server configuration, the web application should not process unnecessary HTTP requests either.

Forcing the HTTP-POST method

When operating a web application, data is normally transmitted to the web application (e.g. form data or the SessionID). This data may be transmitted as parameters in the URL (GET method) or in the trunk of the HTTP request (POST method).

When using the GET method, confidential data such as form data is visible in the URL (e.g. in the browser history) and may be logged and stored by intermediate systems.

Therefore, data worthy of protection should only be transmitted using the POST method. In this case, it must be taken into consideration that frameworks often abstract the HTTP request method. If the framework is configured improperly, this may result in both methods still being admissible despite the forced limitation to the POST method by the web application (e.g. by redirecting an HTTP-GET request to an HTTP-POST request by the framework).

Securely handling SSL/TLS

In order to protect the transmitted data between web application and user client, the transport channel can be protected by cryptographic methods (e.g. SSL/TLS). Confidential data should always be transmitted using an encrypted transport channel (see also S 5.66 Use of TLS/SSL).

Moreover, it must be ensured that no switch-over to an unencrypted connection takes place in the event of errors occurring while the SSL/TLS connection is being established or while the data is being transmitted using an encrypted channel. Instead, the connection should be re-established or rejected. It must be prevented that confidential data is transmitted using an insecure connection (e.g. by setting the secure flag for cookies; see S 4.401 Protection of confidential data in web applications).

Character coding configuration

The data transmitted between the user client and the web application may be present in different coding. Depending on the expected coding, the client, web application, or the background system data is interpreted differently. The web application should also specify the character coding scheme (e.g. UTF-8) in the header fields of the HTTP response when delivering websites so that the clients provide the web application with the data disposing of the proper coding.

If the web application is used internationally, it should be observed that all international character sets are supported on all logical levels of the web application and by the connected background systems.

Storing configuration files outside of web root

Configuration files of the web application frequently contain information worthy of protection, e.g. access data. Therefore, users of the web application must not have any access to the configuration files.

For this reason, configuration files should only be stored outside of the web server's root directory. Normally, no data is delivered by the web application outside of this directory.

As a matter of principle, configuration data must be stored outside of the source text in separate configuration files. Configuration settings containing confidential data should additionally be encrypted.

Definition of thresholds

Some protection mechanisms provide for the use of thresholds (see e.g. S 4.396 Protection against unauthorised automated use of web applications). If a threshold is exceeded, a corresponding function or resource is often blocked temporarily. This way, several failed login attempts may cause the user account to be blocked (e.g. in order to see off brute-force attacks).

Safeguards initiated this way may influence the operation of the web application and therefore also affect users not involved. For example, these users may no longer be able to log in to the web application once their user account was blocked.

These effects should also be taken into consideration when defining thresholds, thus.

Restrictive file system authorisations

Web applications often provide the users with direct or indirect access to the underlying file system (e.g. using retrievable files or an upload feature). Along with access restrictions at a web application level, these should be protected additionally by restrictive file system authorisations so that an attacker is not able to read or manipulate files worthy of protection in an unauthorised manner. The server the web application is executed on must be started with restricted rights and not as the administrator (root).

Administrating a web application

The web application should be administered predominantly using a system uncoupled from the application. In the event of an e-commerce application, the items may be maintained using a separate system with access to the database of the web application, for example. The system should ideally be intended for this purpose alone and not have any direct connection to the web application. Accordingly, the web application should only retrieve the item data from the database.

Web applications frequently offer a web interface on the same server for administration purposes. This function should be avoided and the administration should be performed using a separate system instead. If the administration must be performed on the same server, the administration interface should only be available from the administration network and access by normal users of the web application should be prevented. It should not be possible to use options for administering the web application that are not used (e.g. console).

Review questions:

© Federal Office for Information Security. All rights reserved.