S 4.397 Logging security-relevant events of web applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

Security relevant events (e.g. accesses to resources, authentication attempts) must be logged comprehensibly so that the logged data can be used for finding the cause in the event of failures or errors or upon attempted attacks.

Along with the recommendations in the safeguards S 5.9 Logging on the server and S 2.110 Data protection guidelines for logging procedures, the following items should be taken into consideration additionally when logging security-relevant events of web applications.

Events of web applications to be logged

In addition to logging on the server and background systems (e.g. operating system, web server, database), the web application should also log security-relevant events. At least the following events should be logged at an application level:

• successful and unsuccessful login attempts for the web application,
• failed authorisation attempts when accessing resources and functions of the web application,
• failed validation of input and output data,
• occurred errors (e.g. exceptions),
• changes to authorisations for users or user groups of the web application (e.g. access rights),
• changes to user accounts (e.g. password change),
• deletions of the web application (e.g. input),
• detected manipulation attempts and unexpected changes (e.g. login attempts using invalid or expired SessionIDs),
• administrative function calls and changes to the configuration (e.g. retrieval of user data, activation and deactivation of logging).

Features of events to be logged

In order to be able to comprehend security-relevant procedures on the basis of logged data, basic features of the events must be available. Therefore, at least the following features should be logged:

• date,
• time, including time zone,
• associated user name,
• affected object (e.g. user account, file, data source),
• status of the activity (e.g. failed, successful),
• place of occurrence (e.g. component),
• activity (e.g. authentication, authorisation),
• severity (e.g. notification, warning, error).

Furthermore, it may also be helpful to log the following features:

• source IP address,
• references to the SessionID (not the SessionID itself),
• IT system the error occurred on,
• software status (version) of the web application.

Confidential and security-relevant data (e.g. SessionID, access data) should not be logged.

Suitable data formats and mechanisms

The logged data should be stored in a uniform format so that efficient analysis is possible. For this reason, the logging component of the web application should use a file format that can be integrated into existing solutions. For example, if a central component is used for analysing the logged data, data formats supported by this component should be selected.

Server-side logging with the help of a central component

The logging function of the web application must only be executed on the server, since this is the only way to analyse the logged data in a centralised manner. The logged data should be captured by a single, central logging component of the web application and not by different logging components.

A new development of the logging component prone to error should not be used. Instead, the functionality of established frameworks should be used generally supporting one central logging approach and logging in common log data formats (see section Suitable data formats and mechanisms).

Protection against unauthorised access and manipulation of logged data

Since the logged data may include confidential information (e.g. regarding the user behaviour and the structure and/or configuration of the web application), any access to the logged data must be controlled and only authorised users must be granted access. It must not be possible to access the logged data using public interfaces of the web application. The logged data should therefore be stored outside of the web root directory of the web server.

If the logged data is stored to a database, the logged data should be separated from the actual user data. This separation may be achieved by means of a separate database table. Furthermore, a separate database user for the logging function may increase the protection of the logged data. In this case, the database user must not have any access rights to the logged data for the user data.

Alternatively, the logged data can also be stored to a separate database instance for web application with high protection requirements.

Secure log analysis

An attacker may deliberately provoke log entries (e.g. if input fields are logged) containing malicious program code. Therefore, it should be ensured when the logged data is analysed that malicious code in log entries is not interpreted by the analysis program (e.g. by viewing it in a browser and interpreting JavaScript code in the logged data).

Since no changes to the logged data may be performed when analysing the logs, logged data must only be analysed in a read-only mode.

Time synchronisation

The logged data of different components of a web application (e.g. application servers, web servers, database servers) must be correlated normally in order to be able to completely comprehend cross-component procedures. For this, the time on the systems should be synchronised in order to be able to consistently comprehend procedures in the logs taking the times as a basis. For this, S 4.227 Use of a local NTP server for time synchronisation should be taken into consideration.

Review questions:

• Does the web application log security-relevant events with the required features?
• Is no confidential data (e.g. access data) logged?
• Is logging only performed by a central component of the web application on the server?
• Are only authorised users allowed to access the logged data?
• Is accessing the logged data using the public interface prohibited?
• Does the web application use data formats and mechanisms for logging allowing for integration into existing solutions?
• Is a time synchronisation implemented for the components of the web application?
• Is the execution of malicious code prevented during log analysis?