Application Level DoS - The Lagging Nightmare

Summary

Application-level Denial of Service (DoS) refers to a type of attack that aims to disrupt the availability or functionality of a web application by exploiting vulnerabilities or weaknesses in its software or infrastructure. Unlike traditional network-level DoS attacks that target network resources or infrastructure (e.g., flooding a server with excessive traffic), application-level DoS attacks specifically target the application layer, exploiting flaws in the application’s logic, design or implementation.

Description

I have found an application level denial of service attack on one of the website. The functionality was to create a data ticket and add some details where I need to add the Title, Description, Location and Creation Date where the description field was vulnerable to this attack. The description field had a character limitation of 250 but if manipulated on the client side, it was not checking the limitation on the server side which led to this issue. Using inspect element I change the maxlength value from 250 to 2500000000000000000 and entered 2102042 non ASCII characters that takes time in processing. The characters I used are termed as mathematical script small letters, which are part of the Unicode standard. They fall under the range U+1D4EA to U+1D503 in the Unicode block “Mathematical Alphanumeric Symbols”.

Here are some examples of Unicode code points:

• 𝓪: U+1D4EA
• 𝓫: U+1D4EB
• 𝓬: U+1D4EC
• 𝓭: U+1D4ED
• 𝓮: U+1D4EE
• 𝓯: U+1D4EF
• 𝓰: U+1D4F0

The uncommon behaviour I noticed in this vulnerability was I tried the attack using Firefox and only Chrome and Edge browsers were vulnerable to this, so I did the research why Firefox is not affected from this vulnerability and only Chrome and Edge are affected and found the below conclusion

Impact on Different Browsers

The vulnerability affected Chrome and Edge but not Firefox, which can be attributed to differences in how these browsers handle large inputs and render content. Here are some potential reasons:

1. Browser-Specific Handling of Large Inputs:

Chrome and Edge:

• Both browsers use the Blink rendering engine, which can have specific behaviors or limitations when processing and rendering large amounts of text.
• Large Unicode inputs (such as mathematical script small letters) can cause excessive memory usage or rendering issues specific to Blink.

Firefox:

• Firefox uses the Gecko rendering engine, which can be capable of handling large inputs more efficiently or have better memory management in this context.
• Different internal optimizations could lead to less impact from the same large payload.

2. Rendering Engine Differences:

Blink (Chrome and Edge):

• Blink can be more sensitive to large Unicode text inputs, causing significant memory usage or rendering performance issues.
• Differences in text rendering, memory allocation, or garbage collection can lead to variations in behavior under stress.

Gecko (Firefox):

• Gecko can have optimizations that better manage large text inputs, preventing the same level of resource exhaustion.
• Efficient handling of Unicode and complex script rendering could mitigate the impact.

Anatomy of Mathematical Script Small Letters

1. Unicode Size: Mathematical script small letters are encoded in Unicode, each character being represented by multiple bytes (typically 3-4 bytes per character in UTF-8 encoding), compared to single-byte ASCII characters. This increases the overall size of the payload.
2. Complex Rendering: These characters requires more complex rendering and processing compared to simple ASCII characters, adding further strain on the server’s processing capabilities.
3. Increased Data Size: When user inputs 2,102,042 mathematical script small letters, the total data size is significantly larger in terms of bytes compared to the same number of ASCII characters. For example, if each character is 4 bytes in UTF-8, the total size of the input is approximately 8,408,168 bytes (about 8 MB). This is much larger than the equivalent ASCII text.

Anatomy of Front-end Restriction Bypass & Back-end Processing

Front-end Restriction Bypass

1. The description field had a front-end restriction of 250 characters, implemented via the maxlength attribute in HTML.
2. By using browser developer tools (Inspect Element), the attacker modifies this attribute to accept a much larger input, effectively bypassing the client-side validation.

Data Submission

1. An attacker submits a payload containing 2,102,042 characters, specifically using mathematical script small letters, which are part of the Unicode standard and are larger in size compared to standard ASCII characters.

Back-end Processing and Impact on Server Resources

1. Input Handling: When the server receives this massive input, it needs to handle and process the data.
2. Validation: Ideally, the back-end should also validate the input size and reject anything exceeding the intended limit. If this validation is missing or inadequate, the server proceeds with processing the large payload.
3. Memory Allocation: The server allocates memory to store the incoming data. Large inputs require substantial memory allocation, which can strain the server’s resources.
4. CPU Utilization: Processing, storing, and logging such a large input increases CPU usage.
5. Database Load: If the description field is stored in a database, writing such a large entry can cause delays and increased disk I/O, leading to further performance degradation.

Denial of Service (DoS)

1. Application-Level DoS: The server becomes overwhelmed by the resource demands of processing the large input, leading to slow response times or complete unavailability. Other legitimate requests are delayed or dropped, effectively denying service to users.

Back-end Workflow and Endpoint Behavior

1. When a user enters the data, the server processes the input and stores the data in a database or some form of persistent storage. The description field, filled with 2,102,042 characters of mathematical script small letters, gets saved in this storage.
2. The endpoint is responsible for fetching and displaying all data tickets or a list of data tickets. When another user accesses the endpoint, the server retrieves the stored data tickets, including their descriptions and renders them to be displayed.

Reasons for Endpoint-Wide Denial of Service

Database Query and Response Size:

• When the endpoint is accessed, it queries the database to retrieve all data tickets
• The query result includes the data ticket created by the user with the large description, increasing the size of the response
• If a data ticket with such a large description exists, then database query and the response size can become immense, overwhelming the server’s ability to process and transmit the data efficiently

Memory Usage:

• Loading a large amount of data into memory (for instance, 2,102,042 characters per data ticket) can cause the server to use excessive amounts of RAM
• This can lead to memory exhaustion, causing the server to slow down, swap to disk, or crash entirely

Rendering Overhead:

• Rendering the ticket data, especially if it involves converting Unicode characters to a displayable format, can be CPU-intensive.
• Mathematical script small letters require more complex rendering compared to ASCII characters, increasing CPU usage.

Network Bandwidth:

• Transmitting large responses over the network consumes significant bandwidth.
• If the response size is too large, it can disrupt the network, causing delays or timeouts for other requests.

Vulnerability Flow

How I found this vulnerability ?

1. I went to endpoint where I had the functionality of adding details and click on one of the ticket to edit the details

Details Page

2. Then I click on edit button for editing the description field value

Editing

3. I changed the maxlength value of description field from 250 to 2500000000000000

Changing Maxlength Value

4. Then I entered 2102042 mathematical small script characters and clicked on save

Mathematical Small Script Characters

5. Using two different accounts with different browser I visited the endpoint which shows all the data tickets

Chrome

Edge

NOTE: Whenever such issues are identified it is advisable to cross check the issue using different accounts with different browsers.

Why this happened ?

In my opinion,

It happened because of the following reasons

• The server relies on client-side validation (maxlength attribute in HTML) to limit the size of the input.
• By modifying the client-side code (using browser developer tools), any user was able to bypass this restriction and submit a much larger payload.
• The server fails to handle large inputs, leading to high memory and CPU usage, which results in application-level DoS.
• Mathematical script characters are more complex than standard ASCII characters, requiring more processing power to render.
• The rendering engine of a browser needs to handle the intricate shapes and styles of these characters, leading to higher CPU usage and potentially more memory consumption.

Impact

By submitting an excessively large amount of data an attacker can consume server resources such as memory and CPU, causing the application to become unresponsive or crash. This can result in downtime and loss of data tickets for legitimate users.

CVSS Calculation

Vector String - CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

Score - 4.9 Medium

NOTE: You can change the CVSS scoring according to the privileges you required to exploit this vulnerability. Normally it does not require any privileges but in my case it was needed.

Mitigation

It is recommended to implement the below mitigations to prevent from this kind of vulnerabilities

1. Server-Side Validation:

• Enforce strict size limits on input fields to prevent excessively large submissions.
• Validate all inputs on the server side, regardless of client-side restrictions.

2. Efficient Data Handling:

• Use efficient data structures and algorithms to manage large inputs.
• Implement streaming or chunked processing to handle large data more gracefully.