Application Level Denial of Service - A Comprehensive Guide, Part 1

DZone 's Guide to

Application Level Denial of Service - A Comprehensive Guide, Part 1

Denial of Service attacks are some of the oldest, but most effective, ways to exploit a vulnerability. Read on to get a security expert's overview of DoS attacks.

· Security Zone ·
Free Resource

Denial of Service attacks that bring down popular websites often involve thousands of hacked consumer devices and servers. While these attacks mainly aim to overwhelm the target system with traffic, in order to deny service to legitimate users, bugs at the Application Layer (Layer 7 in the OSI model) can have the same effect.

Application Level Denial of Service (L7 DoS) errors are often tough to identify and sometimes even tougher to prevent. This guide aims to highlight the different techniques that will help you find out what to look for and where DoS conditions may occur.

Random Access Memory (RAM)

In order to function properly, applications need a certain amount of available RAM. While it's possible to deal with the system not being able to allocate new memory, most of the time the application will either hang or crash, both of which will result in a DoS scenario.


Recursion is a common reason for L7 DoS attacks. It refers to a procedure that causes itself to repeat over and over again. In most cases, this is a controlled process and a valid technique in programming. However, in the case of L7 DoS, it's the result of a small set of instructions whose execution prompts vulnerable applications to enter a resource-intensive loop, with the specific purpose of exhausting their resources.

This table lists examples that involve a system's volatile memory.

Recursive File Inclusion

What to look out for

Here is an example of PHP code:


PHP allocates new memory for each inclusion and repeats the process until there is no memory left. When running the code in Command Line Interface (CLI) mode, there is no check to break this loop. However, mod_php for Apache has a safety switch that aborts script execution if it detects too many repetitions. In addition, it throws an internal server error. However, a multithreaded script running on a single machine can query the page repeatedly, leading to the same end result – PHP running out of memory. This behavior may also apply to other programming languages.

Where it is found

This kind of vulnerability can be found in places where a traditional Local File Inclusion (LFI) vulnerability might occur. However, because it doesn't need to traverse directories and its PHP extension, it affects otherwise non-exploitable LFIs.

Zip Bombs

What to look out for

In the early 2000s, ZIP bombs were emailed to unsuspecting victims in order to crash their personal computers or mail servers. Ironically, this was often the fault of the system's antivirus program's automated extraction of the archive (in order to scan it), not that of the user opening it. Now, most antivirus vendors would either detect ZIP bombs or avoid extracting them completely. Briefly, some file compression algorithms work by replacing recurring patterns in the file with short references to a single occurrence of the pattern. Let's say that instead of writing 'AAAAAAAAAAAAAAAA,' you could write '1-16-A' to display the character 'A' sixteen times at position 1. Replace '16' with '999999999,' and you'll understand why a relatively small file can consume all the RAM or disk space once extracted. One famous example of a ZIP bomb is 42.zip, which is just 42 kb in size, but increases to 4.5 petabytes (approximately the size of 1.125 billion MP3 files). Even though it is called a ZIP bomb, it can be applied to similar formats.

Where it is found

Web applications that allow you to upload compressed files, and extract the contents for you, might be susceptible to such an attack, particularly if the application (or the library that handles the decompression) fails to conduct a proper inspection of the deflated file.

Billion Laughs Attack

What to look out for

This attack is a classic example of a relatively small set of instructions that leads to the generation of a massive amount of data once it is parsed. This is how it works. At first, a single entity is created. In most available examples, it's called lol and its sole content is the word 'lol.' Then another entity is created, called lol1. This entity contains ten references to the first lol entity. The entity lol2 contains ten references to lol1 and so on. This is repeated several times. If the parser expands all the entities, it will reach a size of 109 'lols' – one billion laughs.

Where it is found

You may encounter this vulnerability wherever an application accepts input formatted as XML and parses it on the server side. Various examples are available online, one of them on the linked Wikipedia page above.

Tricking an Application Into Allocating a Huge Amount of Memory

Sometimes applications can decide how much memory they need to allocate just by looking at file headers or serialized strings. If an attacker manages to manipulate these indicators, the application can be tricked into allocating large chunks of memory with very little effort.

Deserialization Vulnerabilities

What to look out for

Deserialization is a delicate topic and you should generally not deserialize user-supplied input using functions that are not explicitly recommended as a safe alternative to raw deserialization functions. However, depending on their implementation, even those functions may contain bugs that lead to a DoS condition. It might be possible to pass a string to a deserialization function that instructs the parser to allocate large chunks of memory (for example, by using a repeating nested array of definitions as seen in the linked paper below about various PHP vulnerabilities). A wide range of programming languages with a similar functionality, in addition to PHP, can be vulnerable.

Where it is found

Deserialization vulnerabilities may be found everywhere user input is accepted. Most of the time you can see where serialized strings are accepted by using the application normally and intercepting the traffic with a tool like Fiddler.


Reading Infinite Data Streams

What to look out for

Reading infinite data streams using an LFI can create a DoS condition, where there is no check on the maximum readable amount of data. On Linux, the first choice for a data source would be either /dev/zero  (infinite stream of NULL-bytes) or /dev/urandom (infinite stream of random data). In both cases, enough memory would be allocated to crash the application.

Where it is found

This vulnerability can be found in places where a user can specify which data is either read from the file system or from a remote server. As mentioned above, on the local Linux system, /dev/zero or /dev/urandom are the preferred options.

Central Processing Unit (CPU)

The CPU is responsible for the execution of the instructions you write into your program. Depending on the task, the CPU may have relatively little work to do; alternatively, it may require large amounts of computing power. Work-intensive tasks may even tie up all of the CPU's resources and render the system unresponsive.


Recursion is not only a matter of RAM. If the CPU is forced to repeat a resource-intensive task, it will stop responding to subsequent requests until the task is finished. There are a few attacks that abuse this fact.


What to look out for

reDoS (Regular Expression Denial of Service) was put under the spotlight in 2016 when it caused stackoverflow.com to go offline for just over 30 minutes. It wasn't the fault of an attacker, but a user who included 20,000 whitespace characters in a code snippet. According to the write-up, the regular expression was written in such a way that it forced the system to check the 20,000 character strings in 200,010,000 steps (20,000 + 19,000, + … + 2 + 1). There are more details on both the OWASP page and the StackOverflow blog post, but other sites also provide a useful examination of the issue.

Where it is found

If a web application allows you to input your own regex code, it might be possible to execute the above-mentioned attack. In older versions of PHP, it might even lead to remote code execution.

SQL Injection Wildcard Attack

What to look out for

An SQL injection wildcard attack works in a similar way to a plain reDoS. The key difference is that it doesn't just use the usual regular expression syntax, but employs so-called 'wildcards' that are used by databases to find data matching a specific description. These attacks can either be carried out using an (otherwise not vulnerable) search functionality, or via an attack vector, where it's possible to execute SQL statements, for example with an existing SQL injection vulnerability.

Where it is found

Due to the nature of the vulnerability and the affected SQL functions, it can often be found in search functionality. To learn more about how such attacks are conducted, see the linked paper.

Fork Bombs

What to look out for

Fork bombs are processes that duplicate themselves over and over again until they use up all of the system's resources. Both the CPU and the process table are affected. They acquired their name from the fork system call that they use. Perhaps the most commonly-known fork bomb is the following shell command:  :(){ :|:& };:. This shows that fork bombs use recursion, as the  :  function calls itself over and over again. Fork bombs are rarely used in web application attacks.

Where it is found

This attack would be conducted in a sandboxed environment that allows code execution of some sort, without giving an attacker access to sensitive data. Otherwise, an attacker might decide to use the code execution for malicious purposes that are worse than a Denial of Service attack.

Abusing Resource-Intensive Operations

It is often possible for a user to instruct the server to execute a resource-intensive set of instructions. These don't necessarily involve recursion. Instead, they are often CPU-hungry operations, that are either designed to be ineffective or require a large amount of computing power to carry out the instructions.

Abusing Password Hashing Functions

What to look out for

Why would anyone purposefully design a set of instructions that take a long time to execute and require a lot of computing power? One possible application is abusing password hashing functions. The reason is simple. Modern password hashing functions are designed to be ineffective, which is achieved by so-called 'key stretching.' They need a lot of time and resources to return the desired output. This is intentional because it slows down attackers that are trying to find the passwords belonging to those hashes. This property distinguishes these algorithms from the ones used in other kinds of hashing functions. These are generally designed to quickly return checksums for large files.

Where it is found

Attackers could abuse this fact to achieve a DoS attack if they submitted a huge amount of long passwords to the hashing function. Depending on the cost factor and server hardware, this could easily lead to a DoS.

Headless Browser SSRF

What to look out for

Headless browsers are sometimes used to visit user-supplied websites and easily render the DOM, in order to take a screenshot of the page that was submitted. There are several vulnerabilities that can arise when using such a setup, such as the disclosure of local file contents or a classical Server Side Request Forgery vulnerability that allows interaction with services behind your firewall. But even if those obvious flaws are considered, it is still possible to exhaust the server's resources by instructing it to parse JavaScript code that was placed on your website. This might lead to a DoS condition.

Where it is found

Code that leads to a high CPU load might be JavaScript-specific reDoS or even cryptocurrency mining, the latter being limited by the hardware in use and connection timeouts.

Tune in tomorrow when we'll wrap up our list! 

application level, denial of service, dos, layer 7, security

Published at DZone with permission of Sven Morgenroth , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}