S 4.395 Error handling by web applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

If an error occurs while the web application is operated, this error should be handled in such a way that a consistent state of the web application is guaranteed and therefore data protection is maintained.

A web application is in an inconsistent state if it is switched to an unexpected state due to an error and data is therefore processed in an uncontrolled manner (e.g. no error message if data is stored unsuccessfully).

The consistent state of a web application may be jeopardised by the following events, amongst other things:

• crash of the application
• incomplete transactions at an application level
• performance of an activity despite errors (e.g. in the event of incomplete tests by security components)
• prevention of services (denial-of-service)
• privilege escalation
• execution of malicious code (code execution)

The following items should be taken into consideration during error handling:

Avoidance of confidential information in error messages

The web application must provide the user with neutral, adapted error pages not containing any confidential information in the event of an error (see also S 4.400 Restrictive disclosure of security-related information in web applications).

Error logging

For the occurred errors to be completely comprehensible, the errors must be logged as events according to S 4.397 Logging security-relevant events of web applications.

Cancellation of the activity upon occurrence of an error

If errors occur in relation to security components of the web application (e.g. during authorisation or authentication), the prompted activity must be cancelled and access to the requested resource or function must be denied. It must be ensured that no security mechanisms can be bypassed with the help of provoked errors.

For web applications with high protection requirements, invalidating a possible active session should be taken into consideration additionally (see also S 4.394 Session management for web applications).

Release of reserved resources

During operation, a web application usually uses resources such as network or file streams in order to be able to access background systems, cached states, or other data. While the web application accesses these resources they are often reserved for exclusive access by the web application and cannot be used by other processes.

If an error occurs, previously reserved resources (e.g. file handle to a temporary file) should be released within the framework of error handling. Furthermore, cached data must be deleted during error handling.

Immediate error handling

Errors in the web application should be handled by the web application itself. Forwarding an unknown error to another component (e.g. application server) may result in a loss of information required in order to handle the error (e.g. for releasing bound resources). Therefore, errors should not be forwarded if they were not yet handled.

Avoiding too high an error tolerance

If the reasons for erroneous states are not clarified entirely, the error should not be tolerated, e.g. for reasons of user-friendliness, but the activity should be cancelled in cases of doubt. Fatal errors should always cause the activity to be cancelled.

The aim is to achieve a robust and error tolerant web application that is able to differentiate the intended use by the user from obvious misuse attempts and fatal errors and that is able to react accordingly.

Review questions:

• Does the web application only issue error messages not containing any confidential information?
• Are the errors logged?
• Is a prompted activity cancelled in the event of an error and is access to the requested resource or function denied as a result?
• Does error handling provide for the release of bound resources?
• Are errors handled by the same component the error occurred on, where possible?