T 2.157 Poor selection or conception of web applications

A web application generally uses a distributed, complex system and consists of various components (e.g. web servers, application servers, background systems) and associated interfaces. In many cases, these are integrated in an existing infrastructure, in which case the protection of the data must be ensured throughout all components and interfaces.

Individually developed web applications are usually designed on the basis of frameworks which provide basic functions and must be configured and/or secured according to the specific application. Frameworks, components and interfaces must be selected and their integration and protection considered, as part of the conception.

In contrast, during conception of web applications based on standard software (e.g. content management systems), the selection of the software and the configuration of the subcomponents must be considered, in particular. In this context, standard software means both Free/Libre Open Source Software (FOSS/FLOSS) and commercial software.

Regardless of whether the web application is implemented as individual development or standard software, inadequate consideration of its complexity (e.g. of frameworks, components and interfaces) during selection and conception of web applications can put the protection of the data at risk.

Fundamentally bad decisions during the planning phase may result in vulnerabilities, which possibly cannot be eliminated at all or only through expensive subsequent improvements.

Examples:

Selection of web applications based on standard software

• The application environment does not meet the minimum requirements of the web applications on the hardware and software. As a consequence, integration in the existing infrastructure (e.g. connection to a database or an identity repository) is not possible.
• The selected product does not offer sufficient security functionality to protect data requiring protection against unauthorised access. Therefore, the necessary protection mechanisms must be added subsequently. If the product can not be extended by protection mechanisms, then the protection must be realised by external means (e.g. web application firewall). This causes additional expense.

Design of the software architecture of the web application

• A security function (e.g. authentication, authorisation) is not implemented and used in one place only, but is multiply realised in the web application. If this security function is implemented differently in different places, this results in diverging security levels. Furthermore, the development and maintenance requirements increase in case of redundantly implemented functions.
• The security function is implemented on clients only (e.g. in the web browser). If the configuration of the web browser is manipulated by an attacker, it is possible to bypass the security functions implemented on the clients. The attacker thus gains unauthorised access to data and functions requiring protection.

Integration and operation of the web application

• The background systems are inadequately secured making the database of the web application accessible from the internet. An attacker can thus directly access the database and the data stored therein without using the functions of the web application. The security mechanisms of the web applications are thus bypassed and cannot prevent the unauthorised access to the stored data in background systems.
• Application components or frameworks for session management are used in an insecure configuration. As a result, short SessionIDs with a long runtime are used. It may therefore be possible for an attacker to guess the SessionID of an authenticated user and to take over the assigned session (see T 5.169 Inadequate session management of web applications).

Extension of the web application

• Existing security functions of the web application are disabled due to incorrect implementation of functional extensions. If a form is added to the web application in which the input data is not validated, this can be used by an attacker for unauthorised access to the data requiring protection (e.g. during an SQL injection attack; see T 5.131 SQL injection).