S 5.169 System architecture of a web application

Initiation responsibility: Persons responsible for individual applications

Implementation responsibility: Administrator

Web applications generally use several IT system components such as web servers, web application servers, and background systems, for example. The selection of a suitable system architecture forms the basis for securely operating a web application.

When designing the system architecture of the web application and networking the involved IT systems, the following points should be taken into consideration.

Separation according to server roles

The server services of the web application (e.g. web server, application server, database server) should each be operated on separate IT systems. If this approach allows for exploiting a weakness in the system of an exposed component (e.g. in the web server), the data stored on other system components (e.g. the database) is not affected by the aforementioned.

Server virtualization can also be used for server role separation. If server virtualization is used, module S 3.4 Virtualization must be taken into consideration during implementation.

Limited accounts for server processes of the system components

Separate accounts should be used for the different server processes of the system components (e.g. a separate system user for the web server process). Here, the rights of these service accounts must be restricted at an operating system level to an extent that access is only possible to the required resources and files of the operating system. This way, an attacker only has restricted rights even after having successfully compromised a server process so that access to the operating system level is made more difficult.

Multi-tier network architecture

The IT system components of the web application should be isolated within the security gateway in demilitarised zones (DMZ) according to the protection requirements (see S 2.73 Selecting suitable basic structures for security gateways).

The network architecture should pursue a multi-tier approach. In this, at least the following security zones should be taken into consideration:

• web tier
  
  This tier is adjacent to the untrustworthy network (e.g. internet) and constitutes the exposed tier with direct user accesses. Packet filters between adjacent networks (e.g. application tier and internet) should filter the data traffic so that no direct access from the untrustworthy network exceeding the network borders of the web tier is possible. In this tier, systems having an exposed position and requiring direct user access, for example, should be located, like the web server.
• application tier
  
  The application tier should be adjacent to the web tier on the one hand and to the data tier on the other hand. The network traffic to the adjacent networks should be filtered with the help of packet filters so that no direct access between adjacent networks is possible. In this network segment, the systems and servers with the application logic (e.g. the application server with the web application) should be located. The systems access data from the adjacent data tier (e.g. databases), treat the data, and provide the systems in the web tier (e.g. the web server) with the data.
• data tier
  
  The data tier is the trustworthy zone of the multi-tier architecture. Packet filters between the adjacent networks should control data traffic. In this tier, the background systems of the web application such as databases, directory service, and legacy systems should be located. Access to these systems should only be possible from adjacent networks (e.g. application tier). The data tier must be implement as separate zone and should not be integrated into other zones (e.g. intranet).

It should not be possible to access systems in the intranet from the zones mentioned above. If, for example, a directory service is used for authentication at the web application, a separate domain on dedicated hardware should be used here, when possible.

The data traffic should be filtered by separated filter components (e.g. packet filters). In the event of high protection requirements, the filter components should be superseded or complemented by systems with filter functions at higher protocol levels (e.g. Application Level Gateway). In this case, the Application Level Gateway should be integrated into a separate security zone accepting the queries of the users even upstream of the web tier systems.

Use of Web Application Firewalls

When filtering at higher protocol levels, the Web Application Firewalls (WAF) may be used. Since a WAF analyses the HTTP protocol and the data transmitted using this protocol, attack patterns can already be filtered at the WAF at an application level. This way, attempted attacks are detected prematurely and no longer forwarded to the web application.

Normally, filtering at the WAF may be performed in two ways.

• Data sent to a web application is checked for known attack patterns. The attack patterns are provided by the WAF manufacturer and include both typical character strings used within the framework of general attacks against web applications (e.g. SQL injection) and specific attack patterns referring to default software products. In order to reliably detect known attacks, the attack signatures must be updated regularly just like for a virus scanner.
• If no default software is used or if additional protection is required, separate filter rules can be established for WAF normally. In this way, the input data admissible for the web application is defined. This method requires a high configuration effort and exact knowledge of the data processed by the web application

Review questions:

• Is a separation of the server services to separate IT systems designed for web applications (separation according to server roles)?
• Are limited accounts used for server processes of the system components of web applications?
• Is a multi-tier approach implemented regarding the network architecture of the web application?
• When using Web Application Firewalls: Was the configuration of the WAF adapted to the web application to be protected?
• When using Web Application Firewalls: Are the attack signatures for the WAF updated regularly?