S 4.405 Preventing resources (DoS) of web applications from being blocked

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

Web applications often provide the users resource-intensive functions triggering complex database queries, for instance. If these CPU-intensive operations are called up often deliberately or if the web application is flooded with requests, this can restrict the operation of the web application or even make it unavailable. This procedure is referred to as denial-of-service (DoS) attack.

In most cases, DoS attacks as well as brute-force and enumeration attacks are based on automation (see safeguard S 4.396 Protection against unauthorised automated use of web applications). In order to prevent these DoS attacks, similar protection mechanisms should thus be implemented. This includes, for example, the following safeguards:

In addition, the following examples provide information on specific safeguards to make denial-of-service attacks at the web application level more difficult:

• defining thresholds (for example, the temporary blocking of a resource following repeated inappropriate access),
• artificially delaying the period of time between the request and its processing by the web application (for example, following repeated unsuccessful login),
• temporarily blocking the IP address calling up if you suspect an attack,
• using CAPTCHAs.

In addition, the following examples provide information on specific safeguards to make denial-of-service attacks at the web application level more difficult:

• Resource-intensive operations are particularly prone to DoS attacks. Therefore, the use of resources can be restricted to a maximum for each user. Moreover, specific operations can be accessible only to logged in users (e.g. complex database queries).

• For each user, only one request at the same time should be processed. Several requests of the same user should be processed sequentially.

• The load caused by DoS requests can be drastically reduced in certain cases by caching the website calls. Thus, the CPU-intensive operation called up is not carried out for each call, but only the cached result is returned. Requests put great strains on the resources can also be precalculated at times when the load is low (pre-aggregation).

• The architecture and flow control of the web application should be designed in such a manner that CPU-intensive operations are avoided (for example, when creating the SessionID, resource-intensive operations should be avoided). To detect CPU-intensive operations, load tests can be carried out.

• An overflow of storage space, for example, as part of logging, might result in write access to the data medium no longer being possible. If save operations are carried out by the web application, this might endanger operation. Therefore, the access to data storage devices should be limited and the capacity of the data storage devices checked at regular intervals. Furthermore, memory (RAM) usage should also be limited for each thread.

Review questions:

• Are the use and application of resource-intensive operations avoided for web applications and are these subject to special protection?
• Is a potential overflow of log data monitored and avoided for web applications?