6 common application-layer DDoS attacks – key signals and indicators

Key takeaways:

 

• The six main types of application-layer DDoS attacks use different methods to achieve the same goal: send so many requests to a web server that it stops responding correctly.
• A successful DDoS attack denies legitimate traffic from reaching a website, leaving users frustrated and leading businesses to potentially lose sales.
• Perimeter defenses such as firewalls and monitoring tools can absorb the impact of DDoS attacks, but development teams also need to eliminate vulnerabilities that could be targeted.

Application-layer distributed denial of service (DDoS) attacks come in many forms, and attackers may carry them out for many reasons, but they have one thing in common: they take advantage of the way web applications work to send far more requests than web servers can handle. Organizations can take many preventive measures, including web application firewalls and web traffic monitoring. But they should not overlook the fact that they can also reduce their exposure to such attacks by detecting, fixing, and preventing web application vulnerabilities, even when an app is already in production. 

Understanding the application-layer DDoS attack

A DDoS application-layer attack targets the layer of data within a web app with which the end user interacts. In a typical legitimate interaction, an individual user makes a single request to an application’s web server. In an application-layer DDoS attack, the server is inundated with far more requests than it can handle, or with malicious requests that cause it to slow to a crawl in an effort to respond. This renders the app inaccessible – hence denial of service. You will also see such attacks referred to as layer 7 attacks because the application is the seventh layer in the Open Systems Interconnection (OSI) computing model, as first defined by the International Standards Organization (ISO) in 1994. 

In these scenarios, attackers take advantage of the fact that making a request requires far fewer computing resources than responding to a request. For example, while a user only needs to type a term into a website’s search box and hit Enter, the web server must query a database to return the results of the search. If enough users – or malicious bots, which make up over a quarter of web traffic – run a query, then the server is overwhelmed and the web application becomes inaccessible.

Six of the most common application-layer DDoS attacks 

While there are many types of DDoS attacks in the application layer, these six examples are among the most common. 

• Slow rate: Sending malicious HTTP or TCP requests that appear to be legitimate traffic at a very slow rate. One type of slow rate attack tool, Slowloris, opens a connection to a server but never completes the connection. This causes the server to keep open connections to the maximum number allowed.  
• Slow post: Sending a legitimate HTTP Post Header at a speed slow enough to prevent legitimate users from accessing a server but not slow enough for a connection to time out. 
• Slow read: Sending a HTTP request to a server but reading the response so slowly that other users can’t access the server – but again, not slow enough for a timeout to occur.
• HTTP(S) flooding: Using a botnet network to overwhelm a server with compute-intensive HTTP Get or Post requests that otherwise appear to be valid traffic.  
• Mimicked user browsing: Using botnets to pose as human users to overwhelm a server, cause a website to crash, and make it inaccessible to legitimate users. 
• Large payload post: Consuming a web server’s memory by sending very large XML data structures that must be decoded.  

Signs of an application-layer DDoS attack in progress

Whatever the type of application-layer DDoS attack, there are often three telltale signs that it is happening:

• There’s a lot of traffic coming from clients with similar characteristics, whether it’s mobile device types, browser versions, IP addresses, or locations.
• There’s a significant, unexpected, and unexplainable increase in traffic at a single server.
• Servers are crashing for no apparent reason and/or a website is taking much longer than usual to respond to requests.

It’s worth noting that these signs are similar to unintentional DoS incidents – situations in which sudden spikes in legitimate traffic crash web servers. That’s because DDoS attacks tend to be specifically designed to mimic legitimate web browsing and website use. Some also take advantage of readily identifiable vulnerabilities in how web applications have been developed. 

The motivations behind an application-layer DDoS attack

As with most cyberattacks, those carrying out an application-layer attack may be motivated by a few different factors:

• Send an ideological message by shutting down the website of an individual or organization they oppose. This is sometimes referred to as hacktivism.
• Shut down the website of a commercial or political rival.
• Demand ransom from an attack victim in exchange for stopping an attack.
• Earn the respect of other malicious hackers.
• Use the attack as a diversion to carry out another attack while IT staff are otherwise occupied.
• Hinder the capabilities of an adversary state or organization as part of cyberwarfare campaigns.

The risks of an application-layer DDoS attack

One of the biggest risks of a successful application-layer attack is that it can shut down a website and the services it provides. In the hours that it takes to mitigate a single attack, a business may not be able to take online orders, frustrating existing customers and causing potential customers to go elsewhere. If a public administration website is taken down, critical services may be denied to citizens.

Most malicious hackers don’t stop with a single attack, though. Botnets can be easily programmed to modify their requests to a server. That way, if a website operator identifies patterns in bogus traffic and takes steps to stop it – by prohibiting traffic from a certain IP address, for example – an attacker can adopt another tactic. 

Organizations trying to identify and respond to these patterns using manual processes are likely to find themselves overwhelmed. That could have significant financial implications for any business relying on its website to drive sales, as a website that’s hit by frequent attacks and ongoing outages will see a long-term decrease in legitimate traffic. 

Some key steps to preventing application-layer DDoS attacks

Because bots are often behind some of the most common application-layer attacks, a CAPTCHA test is a simple step that can help prevent bots from flooding a web server with requests. It’s also possible to limit the number of requests that a server can receive or respond to over a certain period of time. However, CAPTCHA can be circumvented with machine learning or brute force, and request limits could hurt a website if legitimate traffic surges when, say, a company’s product receives an unexpected shout-out from a celebrity on social media.

Additional preventive measures for DDoS attacks include:

• A web application firewall that filters and balances incoming server requests as well as outgoing data.
• Packet analysis tools that can discard potentially malicious packets as they come in.
• IP reputation databases that filter incoming traffic.  
• A combination of flow analysis and behavior analysis to determine what “normal” traffic looks like and potentially make abnormalities easier to spot. 

Best practice for protection: Find and eliminate application vulnerabilities

The measures mentioned above can be valuable as perimeter defenses and represent one component of application-layer security protection. However, it’s common to use external services such as Cloudflare to handle this aspect of protection for you. For the things you can control, it’s important not to overlook the application itself, as attackers can also target some of the core features of modern web apps.

One example is HTTP security headers, which are a subset of the HTTP headers that exchange details about HTTP communications. If these headers aren’t configured correctly, they can leave a web app vulnerable to cross-site scripting (XSS), man-in-the-middle (MITM), or clickjacking attacks. Cookies that include sensitive data are another example. With the wrong security attributes in place, or with no attributes set at all, attackers can steal cookies (in XSS or MITM attacks) or gain control of cookies and use them for malicious purposes. 

It can be difficult to identify these types of vulnerabilities during development, as they don’t present themselves until an application is running. That’s where dynamic application security testing (DAST) comes into play. DAST solutions behave like everyday users on the Internet to identify the vulnerabilities that exist in an application in production, inform development teams about the impact of vulnerabilities, and provide remediation guidance. 

DAST can provide security for the software development lifecycle, scanning applications on a regular schedule and – in combination with network-level protections and load balancing – helping to ensure that apps are much less likely to be taken down by malicious traffic.