S 5.21 Web applications
Description
Web applications provide functions and dynamic content over the internet protocol HTTP (Hypertext Transfer Protocol) or HTTPS (HTTP over SSL or TLS, which means protected by an encrypted connection). To accomplish this, documents and user interfaces (for example, control elements and input masks) are generated and delivered to corresponding client programs (web browsers).
Web applications are usually developed on the basis of frameworks. These provide a framework for frequently recurring tasks (for example, for security components). In a web application, several frameworks are often used for different areas (for example, access to databases, formatting of output) and components (for example, authentication, session management). For this reason, security aspects for the selection of frameworks and the software architecture must already be taken into account in the planning phase.
Usually several IT system components are required for operation of a web application. These usually include a web server for delivery of the data, an application server for operation of the application and additional background systems connected as data sources by means of various interfaces (for example, database or directory service).
Web applications are used both in public IT networks (such as the internet) and in corporate networks (intranets) for the provision of data and applications. For this reason, web applications must implement security mechanisms that ensure the protection of the data and prevent misuse.
Typical security components or mechanisms of a web application are:
- Authentication
In order to access protected resources of the web application the users must provide the authentication component with identification (for example, using access data). - Authorisation
Before protected resources and functions are accessed, it must be checked whether the users have the required rights. - Input and output validation
Input and output data must be validated and filtered to avoid processing of malicious data (such as executable malicious code). - Session management
As the internet protocol HTTP does not support any allocation of requests belonging together to a user, this allocation is performed by the session management of the web application. - Error handling
Occurring errors must be handled in such a way that the data of the web application is also protected in case of error. - Logging
Events must be logged by the web application in such a way that executed operations and security-related incidents can also be tracked down at a later point in time.
Scope of the module
This module examines the threats and safeguards applying specifically to web applications. While web servers deliver the web sites (see also S 5.4 Web servers) web applications provide functions and prepare dynamic content for delivery by the web server. The module S 5.4 Web servers also covers the editorial planning of the web site and the business continuity management which is therefore not discussed again in this module. As web services similar to web applications image business logic, a majority of the threats and safeguards of web applications can be applied to the logic components of web services.
In conventional web applications functionality is offered within this application. In SOAP-based web services (Simple Object Access Protocol), however, these are offered by a service provider as loosely connected, independent, interchangeable services over standardised interfaces. Unlike web applications, web services do not usually prepare the output of results for a browser, but provide them in a structured, machine readable form (for example, SOAP messages) for subsequent automatic processing. These data are prepared by different components of the web service (for example, by a parser or by encryption and decryption components). The security-related aspects when realising a service-orientated architecture (SOA) are not discussed in the present module.
Threat scenario
The following typical threats to the IT-Grundschutz in connection with a web application are assumed to exist:
Organisational Shortcomings
| T 2.1 | Lack of, or insufficient, rules |
| T 2.4 | Insufficient monitoring of security safeguards |
| T 2.7 | Unauthorised use of rights |
| T 2.22 | Lack of or insufficient evaluation of auditing data |
| T 2.27 | Lack of or insufficient documentation |
| T 2.67 | Incorrect administration of site and data access rights |
| T 2.87 | Use of insecure protocols in public networks |
| T 2.103 | Insufficient training of employees |
| T 2.157 | Poor selection or conception of web applications |
| T 2.158 | Deficiencies in the development and extension of web applications |
| T 2.159 | Inadequate protection of personal data in web applications |
Human Error
| T 3.16 | Incorrect administration of site and data access rights |
| T 3.38 | Errors in configuration and operation |
| T 3.43 | Inappropriate handling of passwords |
Technical Failure
| T 4.22 | Software vulnerabilities or errors |
| T 4.33 | Poor-quality or missing authentication |
| T 4.35 | Insecure cryptographic algorithms |
| T 4.84 | Inadequate validation of input and output data in web applications |
| T 4.85 | Lack of or poor error handling by web applications |
| T 4.86 | Inadequate traceability of security-related events in web applications |
| T 4.87 | Disclosure of confidential information in web applications |
Deliberate Acts
| T 5.18 | Systematic trying-out of passwords |
| T 5.19 | Abuse of user rights |
| T 5.20 | Misuse of administrator rights |
| T 5.28 | Denial of services |
| T 5.87 | Web spoofing |
| T 5.88 | Abuse of active content |
| T 5.131 | SQL injection |
| T 5.165 | Unauthorised access to or manipulation of data for web applications |
| T 5.166 | Misuse of a web application due to automated use |
| T 5.167 | Errors in the logic of web applications |
| T 5.168 | Bypassing security functions of web applications implemented on the client side |
| T 5.169 | Inadequate session management of web applications |
| T 5.170 | Cross-Site Scripting (XSS) |
| T 5.171 | Cross-Site Request Forgery (CSRF, XSRF, Session Riding) |
| T 5.172 | Bypassing the authorisation in web applications |
| T 5.173 | Integration of third party data and malicious code in web applications |
| T 5.174 | Injection attacks |
| T 5.175 | Clickjacking |
Method recommendation
To secure a web application, other modules will need to be implemented in addition to this module. These modules are selected based on the results of the IT-Grundschutz modelling process.
The operation of a web application requires the use of additional components. For this reason, module S 3.101 General server and, depending on the operating system used, module S 3.102 Servers under Unix or S 3.108 Windows Server 2003, for example, must be examined. Furthermore, the operation of a web application requires a web server (see S 5.4 Web servers).
In web applications, functionality or data are usually migrated to background systems (for example, database and identity repositories). Therefore, depending on the background systems used, additional modules such as S 5.7 Databases and S 5.15 General directory service (or S 5.16 Active Directory) must be taken into account.
If the web application processes personal data or evaluated user data (for example, access statistics, user profiles) module S 1.5 Data protection must be taken in account in addition.
If the web application is operated or developed by external service providers module S 1.11 Outsourcing must be taken in account in addition.
For a secure web application a range of safeguards must be implemented. The phases to complete to accomplish this as well as the safeguards to consider in each phase are listed in the following.
Planning and design
When planning a web application, it is usually necessary to decide whether the requirements for the web application can be covered by standard products or if proprietary development is required. If a web application is implemented based on standard software, alterations beyond mere changes to the configuration, often involving development work are usually required. For this reason, web applications based on standard software must also often meet the requirements for the development and extension of web applications (see S 2.487 Development and extension of applications).
Security aspects must be taken into account already in the design phase of a web application in order to protect the data to be processed (see S 5.169 System architecture of a web application). In this respect, the integration of the background systems (for example, database) and their secure connection should also be taken into account (see S 5.168 Secure connection of background systems to web applications).
If personal data are processed, recorded or evaluated by web applications (for example, user behaviour), the general legal conditions should be taken into account when planning technical solutions (see S 2.110 Data protection guidelines for logging procedures and S 2.488 Web tracking).
Purchasing
If a web application is to be realised using existing standard software a suitable product must be selected (see S 2.80 Drawing up a requirements catalogue for standard software).
Implementation
Before transferral of a web application to production operations the security functions must be configured or developed. The components to be implemented for this purpose must protect the web application against known threats and attack techniques (see, for example, S 2.363 Protection against SQL injection).
Other essential security components of a web application are context-based validation and filtering of the data (see S 4.392 Authentication for web applications) and the protection of user sessions using session management (see S 4.394 Session management for web applications).
Operation
After a web application successfully completed the approval and release procedure and was configured ready for operation, regular operations can be initiated.
In particular, when using the web application over public networks (such as the internet) there is a risk that detected vulnerabilities are exploited. For this reason, processes should be defined to be able to permanently maintain the intended security level of the web application (see S 2.35 Obtaining information on security weaknesses of the system and S 2.273 Prompt installation of security-relevant patches and updates).
It must be ensured that data transmitted by web applications does not contain security-related information that could provide an attacker with information on how to bypass security mechanisms (see S 4.400 Restrictive disclosure of security-related information in web applications).
For a high protection requirement, penetration tests to the web application should be performed in order to check the security level of the web application and to quickly eliminate potential vulnerabilities (S 5.150 Performing penetration tests).
The safeguards for web applications are listed in the following: For reasons of redundancy, the safeguards presented in other modules are not repeated here.
Planning and design
| S 2.1 | (A) | Specification of responsibilities and provisions |
| S 2.11 | (A) | Provisions governing the use of passwords |
| S 2.63 | (A) | Establishing access rights |
| S 2.80 | (A) | Drawing up a requirements catalogue for standard software |
| S 2.363 | (B) | Protection against SQL injection |
| S 2.486 | (A) | Documentation on the architecture of web applications |
| S 2.487 | (B) | Development and extension of applications |
| S 2.488 | (W) | Web tracking |
| S 4.176 | (B) | Selection of an authentication method for web offerings |
| S 4.404 | (A) | Secure design of the logic of web applications |
| S 5.66 | (B) | Use of TSL/SSL |
| S 5.168 | (A) | Secure connection of background systems to web applications |
| S 5.169 | (A) | System architecture of a web application |
Purchasing
| S 2.62 | (B) | Software acceptance and approval procedure |
| S 4.400 | (B) | Restrictive disclosure of security-related information in web applications |
Implementation
| S 4.392 | (A) | Authentication for web applications |
| S 4.393 | (B) | Comprehensive input and output validation for web applications |
| S 4.394 | (A) | Session management for web applications |
| S 4.395 | (B) | Error handling by web applications |
| S 4.396 | (B) | Protection against unauthorised automated use of web applications |
| S 4.398 | (B) | Secure configuration of web applications |
| S 4.399 | (A) | Controlled integration of data and content in web applications |
| S 4.401 | (B) | Protection of confidential data in web applications |
| S 4.402 | (A) | Access control for web applications |
| S 4.403 | (C) | Prevention of Cross-Site Request Forgery (CSRF, XSRF, Session Riding) |
| S 4.405 | (C) | Preventing resources (DoS) of web applications from being blocked |
| S 4.406 | (Z) | Prevention of clickjacking |
Operation
| S 2.8 | (A) | Assignment of access rights |
| S 2.31 | (A) | Documentation of authorised users and rights profiles |
| S 2.34 | (A) | Documentation on changes made to an existing IT system |
| S 2.35 | (B) | Obtaining information on security weaknesses of the system |
| S 2.64 | (A) | Checking the log files |
| S 2.110 | (A) | Data protection guidelines for logging procedures |
| S 2.273 | (A) | Prompt installation of security-relevant patches and updates |
| S 3.5 | (A) | Training on security safeguards |
| S 4.78 | (A) | Careful modifications of configurations |
| S 4.397 | (C) | Logging security-relevant events of web applications |
| S 5.150 | (Z) | Performing penetration tests |