Over a million developers have joined DZone.

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

DZone's Guide to

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

To wrap up this two part series, we examine Logic-Based DoS, how DoS can target disk space, and how bad actors can exhaust a user's resources.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Welcome back! If you missed Part 1, check it out here!

Disk Space

Most programs need more than simply a CPU and volatile memory in order to operate. They also need to be able to write to disk so that they can store information. The generated files are used for caching, configuration, or in order to write to disk in case RAM space is tight. Programs may crash or act unpredictably and whole systems can become unstable.

Uploading Large Files

What to look out for

Arguably the most obvious way to fill a system with data is by uploading large files to the server. If the application doesn't apply proper rate-limiting and size checks for its file upload functionality, an attacker can upload random junk data to the system until it can no longer store any more data. This either makes the file upload functionality fail for legitimate users or can make the entire system unstable.

Where it is found

Profile picture upload functionality, while ubiquitous, is fortunately unsuitable for this type of attack because previous uploads are deleted once a user uploads a new image. Instead, this can be achieved by uploading files in private messages or in bug reports or help desk applications.

Generating a Huge Amount of Databases or Log Files

What to look out for

In the early days of non-relational databases, NoSQL injections could easily be used to execute arbitrary JavaScript on the vulnerable server. Nowadays, however, the available JavaScript functions are greatly reduced and run in a sandboxed environment. Nonetheless, it's still possible to wreak havoc with the whitelisted JavaScript functions, should an attacker achieve code execution. It's possible to either use one of the above-mentioned techniques to exhaust all the available RAM or utilize reDoS to bind all the available CPU resources. However, it's also possible to write into the log files using server-side JavaScript. This results in generating a huge amount of databases or log files if an attacker writes to it in a continuous loop.

Where it is found

Often this attack can be conducted either by directly searching for server-side JavaScript injections or by using features such as MongoDB's $where.

Arbitrary File Deletion

What to look out for

The deletion of arbitrary files is a completely different DoS approach. Using an arbitrary file deletion vulnerability, an attacker can remove data that is necessary for the application in order to work correctly. This may include removing configuration files or even script code in order to deny service to legitimate users.

Where it is found

Where to find such a vulnerability is highly application-specific. But it often involves directory traversal.

Exhaust Allocated Resources for a Single User

On applications or services that allow multiple users, resources are limited and have to be allocated in a fair way. Users can only use a certain amount of available space. It's easy for attackers to fill that space, and deny service for one specific user.

Email Bomb

What to look out for

Users are regularly allocated a small amount of space for their inbox. The goal of an Email Bomb is to flood a user's inbox to the point where all available space is exhausted, and subsequent (legitimate) emails bounce.

Where it is found

Attackers can abuse this flaw by sending a moderately large amount of emails with large attachments. After a short time, the mailbox is full and new emails are rejected. While it should be easy to fill a victim's inbox if space is tight, there is an attack called List Linking that addresses targets with larger inboxes. An attacker registers the victim for various, high-frequency mailing lists and lets them spam the inbox.

Free Website Restrictions

What to look out for

Some web hosts allow only a certain amount of requests per day for users on free subscriptions. If the amount of requests exceeds the maximum limit, the page becomes unavailable for a certain amount of time, except if the user pays for a subscription.

Where it is found

It is relatively easy to trigger this maximum limit by querying the site in a continuous loop, using a tool like cURL. There are only two lines needed in order to create a valid HTTP 1.1 request.

Cash Overflow

What to look out for

A similar approach is called Cash Overflow. Instead of targeting disk space, RAM or the CPU, the attack aims to raise the bill for a service up to the point where it exceeds the allocated amount of money. Should the owner of the website be unable to pay the bill or if an automatic payment fails, the service will be terminated – effectively leading to DoS. This can happen if an external service is used that bills the user a certain amount of money per request.

Where it is found

Since these requests are generally inexpensive, an attacker needs to generate huge amounts of traffic in order to achieve DoS.

Logic-Based Denial of Service

A DoS for specific users might have legitimate reasons - either to enforce rate limiting or to deny access for malicious users. Like every other piece of code, this functionality can contain bugs. And sometimes the application can be tricked into denying service to specific, legitimate users.


What to look out for

Hackers can use a well-known trick, to overcome IP-based rate limiting or blocks, if the application incorrectly uses headers like X-Forwarded-For in order to determine users' IP addresses. It's easy to forget that this flawed implementation also opens the door for a DoS attack if the IP address of a legitimate user is used instead of a random one, for example. Attackers may constantly trigger rate limiting, with an X-Forwarded-For header containing the victims' IP address. If victims can't mask or change their IP address, they are denied service for the duration of the attack.

Where it is found

This flaw can be found on any application protected by a web application firewall (WAF), or any application that applies rate limiting as long as either of these measures can be bypassed using X-Forwarded-For.

Web Application Firewalls

What to look out for

Many web application firewalls can be configured to block users that send malicious requests, for a certain amount of time. Those requests may contain specific, special characters like backticks and single quotes or blocked keywords such as script and passwd. An attacker can set up a page that will send such requests to a WAF-protected website, or in other words, trigger the DoS condition through CSRF. Once it sees the request coming from the victim's IP, it will automatically block it for a certain amount of time. The same works if the attacker is able to set a cookie with a blocked keyword.

Where it is found

This can be found wherever a WAF is protecting the application and users are blocked in the event of malicious keyword detection.

Wasting the Available Password Attempts

What to look out for

Preventing attackers from brute forcing the credentials of legitimate users is difficult. Often this problem is solved using a captcha. But sometimes developers resort to blocking the account after a certain amount of wrong login attempts. If an attacker wastes all of the login attempts for a specific user, either accidentally while brute forcing or on purpose, the affected user will be denied access as well.

Where it is found

This vulnerability can arise wherever there is a limited amount of password attempts per user, rather than per IP address or session. Sometimes applications will send a link to the victim in order to unblock the account again. This should be tested to avoid false positives.

Cookie Bombs

What to look out for

If an application endpoint allows the generation of a big amount of cookies (a cookie bomb) with different names, an attacker can instruct the victim's browser to store and send enough cookies in order to exceed the allowed request size. This will eventually lead to a denial of service condition that can only be fixed by deleting all the malicious cookies.

Where it is found

As mentioned above, the application must have cookies with different names in order for this to work. The attack would be triggered via CSRF.

Basic Tips and Tricks to Identify and Prevent Application DoS Attacks

  • You don't generally need to receive the request responses when conducting a DoS attack. If you want to test for Denial of Service conditions yourself, we recommend that you use HEAD instead of GET requests where possible, or use the Range header with a value of 'bytes=0-0.'
  • Certain methods of error handling are resource-intensive. If you encounter a verbose error, this might indicate that there is a large amount of computing power involved. For example, stack traces are known to be resource-intensive.
  • A small amount of input that leads to an exceptionally large return value is always a good place to look for DoS, especially if recursion is involved.
  • Whenever you encounter a DoS error, you should consider whether this is the worst impact the vulnerability might have. If there is a Local File Inclusion, try to read sensitive information rather than recreating a DoS. And if you can issue a limited set of commands, try to escape from the sandbox and turn it into a full RCE, instead of wasting the system's resources. This helps to more accurately calculate the risk for the developers to which you report the flaw. Should you submit your findings to a bug bounty program, it is also likely to lead to a more lucrative payout.

If we neglected to mention something you think is important, or if you have another idea about where a DoS condition might occur, please tweet us your suggestions and tricks.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

security ,dos ,application level ,cybersecurity

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}