Network-based DDoS attacks, sometimes called “volumetric attacks”, have been around since the early days of the internet. Even though they have been understood and mitigated for decades by service providers like Vercara, they still occur incredibly frequently. We mitigated over 65,000 DDoS attacks of a large or medium size in 2023. It is only because we mitigate these attacks that they do not make the news more often. 

However, as we have seen in several noteworthy DDoS attacks lately, attackers can also use a clever, often more stealthy type of DDoS attack to achieve their goals: application-layer DDoS attacks. You might be wondering, “What is an application-layer DDoS attack?” In this blog, we’ll cover what an application-layer attack is, its indicators, and how you can defend and mitigate it.  

What is an application-layer DDoS attack? 

An application layer DDoS attack, aptly named for the top layer of the TCP/IP model–a combination of layers 5, 6, and 7 on the OSI model, is typically a flood of HTTP/HTTPS requests (but can also use other ports and protocols such as DNS). This technique is designed to overwhelm the application servers of a target rather than its network infrastructure.  

These attacks are becoming more common and effective as they target a critical component of modern businesses: their applications. Application-layer attacks provide several advantages that make them increasingly attractive to cybercriminals that use them. 

By attacking the application itself, these attacks use less bandwidth to cause a similar outage, meaning that the attacker does not have to build as large of an attack platform. And with an attack platform of similar size, they can achieve an even bigger impact. 

The lower volume of network traffic used for an application-layer attack makes it harder to identify that an attack is occurring, especially if the attack is embedded inside of Transport-Layer Security (TLS). When attackers use an application-layer DDoS attack with less network volume, other targets inside the same network remain available for them to attack. 

Application-layer attacks also target security controls upstream of the application server such as on-premises Web Application Firewalls (WAFs) that use many resources such as processor and memory to inspect each HTTP request. By flooding these perimeter protections, the target must turn off the protection for other attacks, like SQL injection, that the attacker can exploit for a data breach. 

Types of application-layer DDoS attacks. 

While network-based DDoS attacks suffocate the server with an excess of bits or packets, application-layer attacks are far more surgical and highly leveraged. They sit at the crossroads of volume floods and server and protocol vulnerabilities, often exploiting complex attack vectors within the application to exhaust system resources that make them harder to detect and mitigate.  

A rogues’ gallery of the most elusive application-layer DDoS attacks includes the following: 

• GET Flood: A brute-force barrage of GET requests overwhelms a server’s capacity, aiming to exhaust memory, CPU, or disk IO. In some cases, a webserver will flood its own outgoing bandwidth responding with large objects. 
• Proxy-Busting Techniques: By adding a random query string to a URL, attackers can generate a HTTP request not matched by an object in cache on a Content Delivery Network or caching server such as Varnish. As a result, that request is forwarded to the application server. 
• Nested JavaScript Object Notation (JSON): API requests concealing deep nested JSON structures that are designed to overwhelm server memory as they serialize the JSON object into an array that grows exponentially instead of linearly. 
• HashDoS: A devious ploy that exploits hash function inefficiencies by having query string variables with the same hash value, causing innocent-looking requests to impose exponential processing loads when the request is serialized. 
• Pagination Attacks: An attack that bypasses pagination limits to query for and process large SQL results sets from the database backing the site. This causes performance degradation as the webserver tries to process the result set and regenerate an HTML page. 
• Overstuffing the Shopping Cart: A type of attack like pagination where the attacker adds many items to their cart on an ecommerce site then repeatedly requests the “view cart” page to generate large database results. 
• RefRef: An attack that uses a large amount of query performance-testing loops generated by the MySQL “benchmark” function inside the database that backs the website. 

• Apache Killer: An HTTP request that exploits a “Range” header vulnerability in Apache server to trigger lethal consumption of server resources as the server loads a copy of the file for every range in the request. 
• WordPress Pingback XML Attack: Abusing the XML-RPC protocol, attackers trigger exponentially increasing responses, effectively crippling the target site. 

 As evidenced by these examples, certain application-layer attacks like GET floods have the potential to target any webserver. However, in many instances, the attack is intricately linked to the web server and content management system. 

A banking site’s web application DDoS footprint. 

Most application-layer attacks are tied to the application and its hosting platform. For example, let us look at a website most of us have used recently: a banking website. They usually have a footprint that includes most of the following: 

• A default or index page, which is frequently targeted by HTTP GET floods, especially in combination with proxy-busting techniques. 
• ATM/branch office locators backed by a database where each query is unique. This can be a target for both pagination and GET floods with unique queries. 
• Advertising landing pages that receive a unique campaign ID that gets logged on to the application server. These make a good target for GET floods. 
• A login/logoff application, which uses a HTTP/HTTPS request to generate a unique database query. This can also be used with a list of usernames that can generate brute-force account lockouts. 
• Password recovery/reset, which is often the same as the login/logoff pages but very frequently forgotten. 
• Large files such as PDFs (Google for “site:targetsite.com filetype:pdf”). When these are requested, the webserver will respond with a large amount of disk and network IO. These could also be targeted in Apache Killer attacks or a functional equivalent. 
• Non-existent pages that generate a 301, 302, 404, etc. response. Most non-200 response codes are not cached on upstream proxies. 
• API endpoints. In many cases, API traffic is less protected than website traffic and does not have adequate caching or scaling. 

Indicators of application-layer DDoS attacks.

Ordinary web transactions are characterized by their predictability, low latency, and minimal impact on server resources without any impact except linear scaling with the number of active users. In contrast, application-layer DDoS traffic exhibits a spectrum of adversarial behaviors: 

• Unpredictable spikes: A sudden surge in transactions that defies the regular ebb and flow, signaling trouble to observant defenders. While application-layer attacks do create additional network traffic, in most cases this is detectable. However, this also looks like a flash crowd, viral content, or effective marketing campaign. 
• Abnormally high latency: A waiting game of extended query times, which manifests as uncharacteristic application sluggishness for the end-user. This latency is easily visible with web performance monitoring services which make sample transactions and report back on availability, latency, and other performance statistics. However, the root cause of latency could also be something other than an application-layer DDoS such as increased user traffic, server failure, network congestion, etc. 
• Server resource overconsumption: A subtle but pervasive drain on server resources—CPU cycles, memory, network bandwidth—culminating in a spontaneous application impotence. In extreme cases this could lead to rolling reboots or loss of control of servers as they stop responding to requests. 
• Intrusion detection alerts: Some application-layer DDoS attacks can be detected by Intrusion Detection Systems/Intrusion Prevention Systems, provided they can inspect the traffic. I.e., they can look at the HTTP requests inside Transport-Layer Security (TLS). 

Detecting and mitigating application layer DDoS attacks. 

Detecting application layer DDoS attacks calls for application-aware protections that can inspect HTTP and HTTPS traffic on a by-request basis.  

By employing anomalous behavior detection, traffic pattern analysis, aggregated log analysis, and network and server resource monitoring, security systems can flag and, in the best cases, block application-layer DDoSes. 

To combat the incursions of DDoS assailants, a multilayered defense strategy is essential: 

• Using cloud-based WAFs: Employ Web Application Firewalls (WAFs) designed to parse and validate every incoming request, which isolate potentially harmful traffic. WAFs can detect exploits against vulnerabilities in the application, perform HTTP request rate limiting, and allow you to create custom rules to block specific techniques that an attacker is using. 
• Network-based protections: Using network-based DDoS mitigation services to mitigate large volumes of known attack traffic allows you to protect controls such as WAF and CDN that are designed to see deep into HTTP requests at the risk of being overwhelmed with the volume of requests. 
• Content Delivery Networks (CDNs): Strategically distribute content to edge servers, dispersing traffic surges and preventing singular points of failure. Most CDNs also incorporate a cloud WAF. 
• Patching and updates: Regular patching of application servers, server frameworks, and applications can remove some of the point vulnerabilities that can be used inside an application-layer DDoS attack. 
• Monitoring and analysis: Distinguishing between a flash crowd and an application-layer DDoS attack can pose challenges. It is imperative to have a Network Operations Center (NOC) and Security Operations Center (SOC) capable of promptly identifying and responding to any potential application-layer DDoS threats. 
• SSL offloading: Divert SSL/TLS decryption processes from application servers to specialized hardware, freeing up crucial computing capacity. 
• Geo-blocking: Blocking troublesome countries reactively when you have no user population in them but you see attacks coming from them. 
• Overprovisioning and load-testing: Scaling network and server resources to respond to an unexpected surge in legitimate user traffic and many malicious requests. 

Application-layer DDoS requires sound strategy and monitoring. 

Effective defense against application-layer DDoS attacks necessitates a strategy comprising proactive defenses within the network and application, regular technology stack updates, continuous monitoring, ad-hoc analysis, and appropriate scalability. By combining these measures, organizations can better protect their online resources and maintain the trust of their users. 

To learn more about how Vercara can help your organization defend against application-layer DDoS attacks, visit our UltraWAF and UltraDDoS Protect product pages. 

Discover how a DDoS attack can impact your business in our blog, What You Can Learn from the Most Well-known DDoS Attacks.