S 4.394 Session management for web applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

Web applications normally use the stateless HTTP protocol for data transmission. It does not support any allocation of requests belonging together to a user such as individual site views for filling a virtual shopping cart, for example. In order to identify requests of a user belonging together and to allocate these to a session, a web application issues a SessionID (e.g. upon successful login) that is then transmitted during every site view. Once the user has logged in to the web application, the SessionID is comparable to his/her access data. The web application uses the SessionID to identify the user during every site view and allocates the user to a (possibly privileged) session. If the SessionID is used by unauthorised persons, they are identified as legitimate users by the web application and may use the application in the name of the victim.

Session management of a web application is intended to manage the sessions and to issue new SessionIDs. In this, the following requirements and aspects should be taken into consideration.

Requirements for the SessionID

It must be ensured that the period of validity of a SessionID (see also section Limited session duration) must be significantly shorter than the time an attacker needs to guess a SessionID. This can be calculated individually for a web application with the help of a formula (see Formula for calculating the basis for assessment regarding SessionIDs in Resources for the Web application module).

The SessionID should at least meet the following requirements:

Protection against unauthorised access to the Session ID

The SessionID may be transmitted both in the URL of a request (GET method), in the trunk of the request (POST method), or as a cookie within the header of the requests. If data is transmitted with the help of the GET method, it may be stored by involved IT systems and therefore be read by third parties (e.g. in the browser history, on screenshots, site copies, or printouts). Therefore, the SessionID should not be transmitted using the GET method (i.e. in the URL). This is not allowed for web applications with high protection requirements. The SessionID should be transmitted preferably with the help of cookies instead.

If the application requires the GET method (e.g. due to compatibility reasons with clients not able to process cookies), the following items must be taken into consideration:

In order to protect the SessionID against being read by unauthorised persons, communication should use a secure connection upon successful login (e.g. with the help of SSL/TLS; see S 5.66 Use of TLS/SSL). The SessionID may be transmitted using an insecure connection if the current session cannot be used in order to use access-controlled areas of the web application. The user is normally not authenticated in this case.

Access to the SessionID as authentication feature should be strictly controlled. If a SessionID is transmitted in the cookie, access to the client-side cookie should be restricted by setting the following flags, where possible (a detailed description of the cookie flags can be found in S 4.401 Protection of confidential data in web applications):

Limited session duration

A web application must provide the users with the option of expressly terminating an active session upon use. Therefore, all websites requiring an authentication of the user in order to be called must contain a clearly visible logout option. Upon successful logout, the session should be terminated completely and the SessionID should no longer be valid. Furthermore, the user should be sensitised for the following behaviours when using web applications:

Unused, active sessions provide a target for brute-force attacks to the SessionID. Therefore, sessions should become invalid after a period of inactivity (idle time). Furthermore, the maximum period of validity should be specified (timeout) so that the SessionIDs of active sessions are also characterised by limited validity. As short a period as possible should be selected for the sessions so that brute-force attacks are made more difficult, whereby the availability of the web application should not be restricted unduly. The formula in section Requirements for the SessionID can be used for determining the appropriate period of validity.

If fatal errors occur while the web application is used, the requested activities should be cancelled and the session should be terminated additionally. Fatal errors include occurring exception errors (exceptions) and recognised attempted attacks, for example. In the event of high protection requirements, even more stringent criteria should be taken into consideration causing the session to become invalid (e.g. invalid input, calling missing sites).

Within the framework of invalidation, the session data should be deleted completely both on the server and on the client so that the session is no longer accepted by the server and the client does not retain any information regarding previously established sessions. For example, this may be performed by deleting the cookies containing the SessionID.

Furthermore, several parallel sessions on the same user account can be prevented. An active session may be invalidated when the user logs in again so that only the new session remains valid. Alternatively, it is possible to maintain the first session over a limited time period (15 minutes) before it is invalidated, for example. In this, a message regarding the expiring, first session should be displayed to the user when he/she logs in to a parallel, second session. This way, still active but no longer used sessions cannot be used or only to a limited extent by unauthorised third parties upon re-login.

In order to provide protection against session-fixation attacks, an already existing SessionID should be replaced by a new one.

A new SessionID should also be issued after switching from an insecure communication channel (HTTP) to a secure communication channel (HTTPS), because the SessionID could have been read by unauthorised persons while it was transmitted using an insecure channel.

Protecting the session data

In order to protect the confidentiality, the accruing session data (e.g. shopping cart) should only be stored on the server on a trustworthy IT system. Furthermore, the data should be protected against unauthorised access by access control mechanisms. If a web application requires the session data to be stored on the client, S 4.401 Protection of confidential data in web applications should also be read regarding data storage on the client.

Allocation of a session on the basis of additional attributes

Along with the SessionID, further features can be used for allocation between user and session (e.g. the IP address). This may render any unauthorised use of active sessions more difficult, since an attacker must know additional features along with a valid SessionID in order to successfully take over the session. The use of additional attributes for allocating a session must at least be taken into consideration for web applications with high protection requirements.

If the IP address is used as an additional feature for session allocation, it must be stored and checked on the server. If the IP address is changed during a session, this should be deemed an attempted attack for applications with high protection requirements, which is why the session should be invalidated. However, it must be taken into consideration that the IP address cannot always be allocated unambiguously to one user. If several users of the web application use a proxy with a consistent (e.g. reverse proxy) or alternating IP address (e.g. alternating, outgoing proxies), there is the risk that the IP address of these users cannot be allocated unambiguously to a session. Thus, it should be considered that some users possibly can only use the web application to a limited extent or not at all.

If the referrer is used as an identity feature, checking for a fixed part of the referred path that remains identical for all accesses (e.g. the domain of the web application) is possible. The users must produce a website of the web application in the referrer. In doing so, it must be taken into consideration that some browsers allow for disabling referrer transmission and content filters possibly filter this field.

The identity features may be distributed to several properties of the HTTP header in order to protect the session against unauthorised use. For example, the following HTTP header information is possible:

Based on the partially low variance of the mentioned features of the HTTP header, the additional protection is limited. On the other hand , the implementation effort and possibly the complexity during troubleshooting are increased. For this reason, whether the additional protection justifies the implementation effort should be weighed up on a case-by-case basis.

Review questions:

© Federal Office for Information Security. All rights reserved.