CON.10 Development of Web Applications

Description

Introduction

Web applications provide certain functions and dynamic (changing) content. For this purpose, web applications make documents and user interfaces available on a server — for example in the form of input masks — and deliver them on request to corresponding programs on clients, such as web browsers. Web applications are usually developed on the basis of frameworks. Frameworks are reusable program templates for frequently recurring tasks. Frameworks also exist for security components.

Web applications must implement security mechanisms that guarantee the protection of the information processed and prevent its misuse. Typical security components or mechanisms include authentication, authorisation, input validation, output encoding, session management, error handling and logging.

Developers must be familiar with the relevant security mechanisms of a web application. For this reason, the development process has a decisive influence on the security of the later software.

Objective

The objective of this building block is to develop secure web applications and to protect the information processed by a web application.

Scope and Modeling

The building block is to be applied to every development project in the information network where web applications are developed.

This building block addresses the specific threats and requirements that are relevant for the development of web applications. Requirements for the secure operation of web applications are not covered in this building block. They are found in the building block APP.3.1 Web Applications and Web Services. Likewise, general requirements for the secure development of software are covered elsewhere — in the building block CON.8 Software Development.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information networks, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block CON.10 Development of Web Applications.

Circumvention of Authorisation in Web Applications

In an attack, attempts are frequently made to access functions or data of web applications that are only available with specific access rights. If authorisation is incorrectly implemented, the permissions of another account with more extensive rights may be obtainable under certain circumstances, thereby granting access to protected areas and data. This is achieved, for example, by deliberately manipulating inputs.

Insufficient Input Validation and Output Encoding

If a web application processes unchecked input data, protection mechanisms may potentially be circumvented. This risk increases if, at the same time, the web application’s output data is transmitted directly to the web browser, the calling application or downstream IT systems without adequate encoding. Such output data can contain malicious code that is interpreted or executed on the target systems. For example, in an attack, JavaScript code can be entered in form data. This malicious code is then unintentionally executed by the IT system processing the web application with the data.

Absent or Deficient Error Handling by Web Applications

If errors occurring during the operation of a web application are not correctly handled, both the operation of a web application and the protection of its functions and data can be impaired. For example, an error can cause the web application to no longer execute correctly and to become inaccessible to clients. Under some circumstances, actions may only be partially performed, cached actions and data may be lost, or security mechanisms may fail.

Insufficient Logging of Security-Relevant Events

If security-relevant events are insufficiently logged by the web application, security incidents can only be retraced with difficulty at a later point in time. The causes of an incident may then no longer be determinable. For example, configuration errors can be overlooked if they do not result in error messages in the log files. Vulnerabilities are also difficult or impossible to identify and remediate with insufficient logging.

Disclosure of Security-Relevant Information by Web Applications

Web pages and data generated and delivered by a web application can contain information about the background systems, such as details about databases or framework version numbers. This information can make it easier to carry out targeted attacks on the web application.

Misuse of a Web Application through Automated Use

If functions of a web application are used in an automated manner, numerous processes can be executed in a short time. Through a repeatedly performed login process, an attack can attempt, for example, to guess valid combinations of accounts and passwords (brute force). In addition, lists of valid accounts can be created (enumeration) if the web application returns information about existing accounts. Furthermore, repeated calls to resource-intensive functions such as complex database queries can be misused for denial-of-service attacks at the application level.

Insufficient Session Management of Web Applications

Insufficient session management can make it possible, without special access rights, to determine the session ID of accounts with extensive access rights. An attack can then use this ID to access protected functions and resources of the web application — for example in the form of a session fixation attack. Here, a session ID with limited rights is first obtained from the web application. This ID is transmitted, e.g. via a link in an email, to more highly authorised persons. If the more highly authorised persons follow this link and authenticate themselves to the web application under the session ID, attackers can subsequently use the application with the full access rights of the legitimate accounts.

Requirements

The following are the specific requirements of the building block CON.10 Development of Web Applications. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and reviewed in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled to the extent that it is sensible and appropriate.

Exactly one role should bear Primary responsibility. There may also be Additional responsibilities. If one of these additional roles has primary responsibility for fulfilling a specific requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be met as a priority for this building block.

CON.10.A1 Authentication in Web Applications (B)

Developers MUST ensure that users securely and appropriately authenticate themselves to the web application before they can access protected functions or content. An appropriate authentication method MUST be selected. The selection process MUST be documented.

A central authentication component MUST be used. The central authentication component SHOULD be implemented using established standard components (e.g. from frameworks or program libraries). If a web application stores authentication data on a client, users MUST be explicitly informed of the risks of the function and must consent to it (“opt-in”).

The web application MUST offer the possibility to define limits for failed login attempts. The web application MUST immediately notify users when their password has been reset.

CON.10.A2 Access Control in Web Applications (B)

Developers MUST ensure, by means of an authorisation component, that users can only perform the actions they are authorised to carry out. Every access to protected content and functions MUST be controlled before it is executed.

The authorisation component MUST take into account all resources and content managed by the web application. If access control fails, accesses MUST be rejected. Access control MUST be in place for URL calls and object references.

CON.10.A3 Secure Session Management (B)

Session IDs MUST be adequately protected. Session IDs MUST be generated randomly and with sufficient entropy. If the web application’s framework can generate secure session IDs, this function of the framework MUST be used. Security-relevant configuration options of the framework MUST be taken into account. When session IDs are transmitted and stored by clients, they MUST be transmitted with adequate protection.

A web application MUST offer the possibility to explicitly end an existing session. After an account has been logged in, an existing session ID MUST be replaced with a new one. Sessions MUST have a maximum validity period (timeout). Inactive sessions MUST automatically become invalid after a certain time. After the session has become invalid, all session data MUST be invalidated and deleted.

CON.10.A4 Controlled Inclusion of Content in Web Applications (B)

It MUST be ensured that a web application only includes and delivers intended data and content.

The targets of a web application’s redirection function MUST be sufficiently restricted so that redirection only occurs to trusted websites. If the trusted domain is left, the web application MUST inform users of this.

CON.10.A5 Upload Functions (B)

Developers MUST ensure that users can only save files in the specified path. Developers MUST ensure that users cannot influence the storage location of uploads. Developers MUST integrate functions into the web application with which uploads can be configured during operation of the web application.

CON.10.A6 Protection against Unauthorised Automated Use of Web Applications (B)

Developers MUST implement security mechanisms that protect the web application against automated access. When implementing the security mechanisms, consideration MUST be given to how they affect the usage possibilities of authorised accounts.

CON.10.A7 Protection of Confidential Data (B)

Developers MUST ensure that confidential data is only transmitted from clients to servers using the HTTP POST method.

Developers MUST use directives in the web application to ensure that no sensitive data is cached on the client side. Developers MUST ensure that no confidential form data is displayed in plaintext in forms. The web application SHOULD prevent confidential data from being unexpectedly stored by the web browser. All access credentials of the web application MUST be protected server-side against unauthorised access using secure cryptographic algorithms (salted hash). The files containing the source code of the web application MUST be protected against unauthorised retrieval.

CON.10.A8 Comprehensive Input Validation and Output Encoding (B)

Developers MUST treat all data passed to a web application as potentially dangerous and filter it appropriately. All input data as well as data streams and secondary data, such as session IDs, MUST be validated server-side.

Invalid inputs SHOULD not be automatically corrected (sanitising) if possible. If, however, it cannot be avoided, sanitising MUST be securely implemented.

Output data MUST be encoded in such a way that malicious code on the target system is not interpreted or executed.

CON.10.A9 Protection against SQL Injection (B)

If data is forwarded to a database management system (DBMS), stored procedures or prepared SQL statements MUST be used. If data is forwarded to a DBMS and neither stored procedures nor prepared SQL statements are supported by the deployment environment, the SQL queries MUST be separately secured.

CON.10.A10 Restrictive Disclosure of Security-Relevant Information (B)

Developers MUST ensure that web pages, responses and error messages of web applications do not contain information that gives attackers hints on how to circumvent security mechanisms.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be met.

CON.10.A11 Software Architecture of a Web Application (S)

Developers SHOULD document the software architecture of the web application with all components and dependencies. The documentation SHOULD be updated and adapted during the course of development. The documentation SHOULD be structured so that it can be used during the development phase and decisions are comprehensible. In the documentation, all components necessary for operation that are not part of the web application SHOULD be identified. The documentation SHOULD describe which components implement which security mechanisms, how the web application is integrated into an existing infrastructure, and which cryptographic functions and methods are used.

CON.10.A12 Verification of Essential Changes (S)

If important settings are to be changed using the application, developers SHOULD ensure that the changes are verified again by entering a password. If this is not possible, the web application SHOULD otherwise ensure in an appropriate manner that users authenticate themselves. Users SHOULD be informed of changes using communication channels outside the web application.

CON.10.A13 Error Handling (S)

If errors occur during the runtime of a web application, they SHOULD be handled in such a way that the web application remains in a consistent state.

The web application SHOULD log error messages. If an initiated action causes an error, the web application SHOULD abort that action. The web application SHOULD deny access to a requested resource or function in the event of an error.

Previously reserved resources SHOULD be released as part of error handling. The error SHOULD be handled by the web application itself where possible.

CON.10.A14 Secure HTTP Configuration for Web Applications (S)

To protect against clickjacking, cross-site scripting and other attacks, appropriate HTTP response headers SHOULD be set. At minimum the following HTTP headers SHOULD be used: Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options and Cache-Control. The HTTP headers used SHOULD be aligned with the web application. The HTTP headers used SHOULD be as restrictive as possible.

Cookies SHOULD generally be set with the attributes secure, SameSite and httponly.

CON.10.A15 Prevention of Cross-Site Request Forgery (S)

Developers SHOULD equip the web application with security mechanisms that enable a distinction to be made between intended page calls and unintentionally forwarded third-party commands. At minimum, it SHOULD be checked whether a secret token is required in addition to the session ID for access to protected resources and functions.

CON.10.A16 Multi-Factor Authentication (S)

Multi-factor authentication SHOULD be implemented.

Requirements for High Protection Needs

The following are examples of proposed requirements for this building block that go beyond the level of protection corresponding to the state of the art. These proposals SHOULD be considered for high protection needs. The specific determination is made within the framework of an individual risk analysis.

CON.10.A17 Prevention of Resource Blocking (H)

To protect against denial-of-service (DoS) attacks, resource-intensive operations SHOULD be avoided. If resource-intensive operations are necessary, they SHOULD be especially secured. For web applications, possible overflow of logging data SHOULD be monitored and prevented.

CON.10.A18 Cryptographic Protection of Confidential Data (H)

Confidential data of a web application SHOULD be secured using secure cryptographic algorithms.

Additional Information

Good to Know

The Open Web Application Security Project provides information on securing web applications on its website.

The Federal Office for Information Security (BSI) provides guidance on the application of cryptographic methods in the document “Cryptographic Methods: Recommendations and Key Lengths: BSI TR-02102”.

The Federal Office for Information Security (BSI) provides guidance on developing secure web applications in the document “Development of Secure Web Applications”.

The Federal Office for Information Security (BSI) provides guidance on the development of secure web applications by organisations in the document “Guide to Developing Secure Web Applications”.