S 4.401 Protection of confidential data in web applications

Initiation responsibility: Persons responsible for individual applications, IT Security Officer

Implementation responsibility: Developer, Administrator

In web applications, data is stored both on the server (e.g. in a web application) and on the clients (e.g. in the browser) and transmitted using networks in so doing. This data may be confidential bank information such as credit card details or bank transfers. Therefore, measures must be taken in order to prevent this data from being read or manipulated by unauthorised persons.

General aspects

If confidential data is processed, transmitted, or stored by the web application (on the server and on the client), it should be protected with the help of cryptographic procedures. Even if the web application is compromised, the cryptographic procedures used should continue to protect this data.

Confidential data of a web application include, for example:

Cryptographic procedures can be used when this data is processed, transmitted, and stored by the web application and the clients. For example, they can be used as follows:

It must be ensured that cryptographic algorithms corresponding to the state of the art and not characterised by any known weaknesses are selected for the respective purpose (see also S 2.164 Selection of a suitable cryptographic procedure). The cryptographic algorithms should be implemented on the server.

The keys used are particularly important in the field of cryptography. Depending on the field of application, these keys must dispose of a certain minimum length and meet different mathematical requirements (e.g. complexity). Furthermore, keys being transported and/or exchanged with the corresponding security must be provided for. The same also holds true for the process of storing the keys. When designing a web application, these items should be considered and summarised within the framework of a crypto-concept (see S 1.7 Crypto-concept).

Additionally, protecting the user data may be required for web applications with high protection requirements. If, for example, the web application processes social data with high confidentiality requirements, this data may be encrypted by the web application before being stored. This way, it can be ensured that no useful data can be read out even if the database is accessed directly (e.g. by the database administrators).

If confidential data is transmitted, the data can be protected against unauthorised reading or manipulation by means of a secure transport channel. Before transmitting confidential data, switch-over to a secure connection should take place. The transmitted data should be protected by a secure connection continuously even after a user logs in. For this, this transport channel is normally protected by using SSL/TLS (see S 5.66 Use of TLS/SSLL).

Protection of data stored on the client

The data exchanged between the client and the web application may be cached by the client in the local browser cache. If the browser stores the data in the cache exceeding the session time of the web application user, this data may be retrieved from the cache by persons having access to the computer of the user or by scripts and browser plugins without any additional access control.

Caching confidential data of the web application on the client may be prevented by the following directives in the HTTP headers of the web application:

Since the web browser is normally not controlled by the operator of the web application, data being cached nevertheless cannot be ruled out completely. Therefore, web applications with high protection requirements may additionally require the user to disable or delete the browser cache while operating the web application as soon as he/she completes his/her activities on the web application. In this case, the user may be provided with a message regarding the deletion of the browser cache upon successful login, for example, This is particularly applicable to web applications used from public IT systems. Alternatively, the user may be made aware of using the private mode of the browser, where no data about the session is cached.

Data is frequently stored in cookies on the client when operating a web application. These cookies are transmitted to the web application transparently for the user during each access to the web application. This may also include data worthy of protection like the SessionID. Therefore, access to cookies containing confidential data should be restricted as far as possible. If the web application creates cookies, the following cookie flags should be set:

The following example shows the instruction for creating a cookie using the mentioned directives:

Set-Cookie: SESSIONID=sl342kdfjslaal39skdj; path=/webapp; secure; HttpOnly

Normally, a HTML form which the user name and the password are entered into is used in order to authenticate the user to the web application. When the user enters his/her password into the password field, it should not be displayed in clear text, but replaced by so-called wild cards (e.g. asterisks or points). For this, the password field type must be selected in the form definition (type="password").

Furthermore, the web browser may be instructed to not to cache confidential form data (e.g. the user name and the password) and not to suggest this as selection when the form is opened the next time. For this, the autocomplete="Off" option should be set in the form header when defining the form.

During the web application session of a user, user-specific data must be stored normally (e.g. items in the shopping cart). In this case, this data may not only be stored on the server, but also on the client in a cookie or in the web storage of the browser. As a matter of principle, transmitting confidential data to the client or storing confidential data on the client should be avoided, because the web application does not have any influence regarding the protection of data stored on the client. This way, the browser may frequently bypass security mechanisms designed for protecting the data implemented on the client (e.g. by local users directly accessing the file system or by cross-site scripting). Instead, confidential data should generally be stored on the server and only the identification feature of the user (e.g. the SessionID) should be stored on the client.

If storing session data on the client is unavoidable, this data should be encrypted and checked for integrity before being processed by the web application. This is to ensure that the data is not read or manipulated by unauthorised persons during transmission.

Furthermore, the data should preferably be stored during the session only and not in a persistent manner. Therefore, the sessionStorage object should be preferred over the localStorage object regarding the web storage mechanism.

Protection of data stored on the server

If the users are to be able to log in to the web application, access data must be stored on the web application. Access data must not be stored in clear text so that it remains protected even after a possible compromise of the web application by an attacker. Instead, the data must be stored with the help of up to date cryptographic algorithms as salted hashes where a random character string is attached to the clear text. In so doing, a different, random salt should be used for every password.

Moreover, the access data should be stored on a trustworthy IT system on the server side (e.g. on the IT system of the web application) and in a protected area (e.g. outside of the web root directory or in separate database tables). The access data should not be stored to the source text of the web application (hardcoded password).

Furthermore, only the web application should be able to access the access data with write authorisations. Only the user should be able to change the access data and only by using the designated interfaces and functions of the web application so that users are not allowed to read, change, or delete access data in an unauthorised manner by means of directly accessing the file system.

If a user opens a website using the web application , the site is normally created by the application during running time. The opened file contains code interpreted by the web application before delivery and returning a website. This website is transmitted to the user.

Normally, these file types are assigned to an interpreter or parser on the basis of the file extension. If the file extension changes, these files are possibly transmitted to the user without having been interpreted beforehand. If such files are opened, the user may view the program logic and any confidential information stored within the code. This may refer to any data the file extension of which is not assigned to an interpreter or parser. Examples of susceptible files include:

The files may contain confidential information such as access data that can be viewed using the aforementioned in the event of insufficient access control.

Therefore, files not designed to be interpreted and retrieved directly by the user should not be delivered by the web application. Additionally, the file system authorisations for these files should be restrictive. Files no longer required should be deleted promptly (see also S 4.400 Restrictive disclosure of security-related information in web applications, section Deleting unused files).

Review questions:

© Federal Office for Information Security. All rights reserved.