Application-Layer Denial of Service

Repeated expensive operations. Repeatedly triggering an operation the application performs that is costly and perhaps unbounded: a login that runs a slow password hash (ironically, the deliberately-slow hashing that protects passwords can be abused to exhaust the server if login attempts are unlimited), a resource-intensive API call, or an action that consumes memory.

Amplification within the application. A single request that causes the application to do disproportionate work internally, such as a query whose complexity the attacker controls, or an operation that expands input into much larger processing.

Why it is hard to distinguish from real users

The defining difficulty, stated plainly for the examination: an application-layer attack can be indistinguishable from legitimate heavy use at the level of individual requests. A real user might run an expensive report; the attacker runs many. A real client might be on a slow connection; the attacker feigns one. So a defender cannot simply block "bad" requests, because they are shaped like good ones, and blocking by volume risks legitimate users doing legitimate but heavy things.

Distinguishing therefore requires context rather than the request alone: is this one source making many expensive requests; is the pattern automated rather than human; is the request expensive out of proportion to any plausible need. This is harder than pattern-matching a flood, which is why the defences are more about designing the application to limit cost than about filtering traffic.

The defences: make the application cost-aware

Because the attack exploits the application doing expensive work cheaply for the attacker, the defences make that work bounded, rate-limited, and, where possible, as costly for the attacker as for the server.

• Rate limiting per client and per operation, especially on expensive operations. A user does not need to run the heavy report fifty times a minute; limiting it protects the resource without affecting legitimate use. The limit is set per the operation's cost, so cheap operations are limited loosely and expensive ones tightly.
• Bounding expensive operations. Cap the size of results, require filters on searches that would otherwise scan everything, paginate large datasets, limit the complexity a request may demand, and set timeouts so no single request can hold a worker indefinitely.
• Timeouts and limits on slow requests. Require a request to arrive within a time limit and a response to be read within one, and cap how long a worker may be held, so slow-request attacks cannot accumulate held workers. This is the direct analogue of the SYN-cookie logic: do not let an incomplete request tie up a scarce resource.
• Authentication and cost for expensive actions. Requiring authentication for the most expensive operations means an attacker must have accounts, which is a barrier; and where appropriate, a proof-of-work or a challenge (such as a CAPTCHA on repeated expensive anonymous operations) makes the request cost the attacker something, restoring the symmetry the attack destroyed.
• Caching. Serving expensive-but-common results from a cache means repeated identical requests cost little, removing the asymmetry for cacheable operations.
• Resource isolation. Ensuring that one expensive operation cannot consume all the server's capacity, for example by limiting the workers or memory a given operation type may use, so the rest of the application keeps working.
• Monitoring for the pattern. Watching for one source making disproportionately expensive requests, or for a rise in slow or incomplete requests, which is the context-based detection the attack requires.

Upstream and application-firewall defences help less here than against volumetric attacks, precisely because the traffic looks legitimate, though modern application-protection services do apply behavioural analysis to spot the pattern. The durable defence is in the application's own design.

A worked example, framed defensively

An assessor reviews an application for application-layer denial-of-service resilience, by examining its behaviour and configuration.

• The search feature accepts a query with no required filters and will return and process the entire dataset, taking seconds of server time per request. Finding: an expensive operation with no bound, exploitable by a small number of requests. Recommendation: require filters, paginate, cap result size, and set a timeout.
• The server has no per-request timeout, so a slowly-sent request can hold a worker indefinitely. Finding: vulnerable to slow-request attacks. Recommendation: enforce request and response timeouts and cap worker hold time.
• The login runs a deliberately-slow password hash and has no rate limit, so repeated login attempts can exhaust processing. Finding: the password-protecting slow hash can be turned into a denial-of-service lever without rate limiting. Recommendation: rate-limit login attempts per source and per account.
• Expensive report generation is not rate-limited or cached. Recommendation: rate-limit and cache.

The report's theme is that these are design findings, not traffic findings: each is the application doing expensive work cheaply for a requester, and each fix makes the work bounded or costly to trigger. The assessor establishes them by examining the application's behaviour, not by attacking it, which is the register of the block.

What beginners get wrong

• Expecting a flood. There is none; the attack uses modest traffic and valid requests, which is why volume-based defences miss it.
• Trying to block by rate alone. The attack's rate may be within normal bounds, and blocking by rate risks legitimate heavy users; distinguishing needs context, and the durable defence is bounding cost in the application.
• Overlooking slow-request attacks. Holding workers with slowly-sent requests exhausts a finite pool with very little traffic, the application-layer analogue of the SYN flood.
• Ignoring self-inflicted cost asymmetries. An unlimited expensive operation, including the deliberately-slow password hash, becomes a lever; rate-limit expensive operations.
• Relying on upstream scrubbing. It helps less here because the traffic looks legitimate; the defence is in the application's design.
• Not requiring filters or bounds on expensive queries. An unbounded search or report is an invitation.

Quick revision

• An application-layer attack exploits cost asymmetry: requests cheap to send, expensive to serve, exhausting processing not bandwidth. Little traffic, looks like real users, so volume-based defences miss it.
• Forms: expensive requests (unfiltered searches, heavy reports), slow requests (holding workers occupied, the SYN-flood analogue at the request level), repeated expensive operations (including abusing a slow password hash without rate limiting), and in-application amplification.
• Hard to distinguish from legitimate heavy use per request; distinguishing needs context (one source, disproportionate cost, automated pattern).
• Defences make the application cost-aware: rate limit per client and per operation, bound expensive operations (filters, pagination, result caps, complexity limits, timeouts), timeouts on slow requests, authentication or challenges for expensive actions, caching, resource isolation, and monitoring for the pattern.

Test yourself

1. What resource does an application-layer denial-of-service attack exhaust, and why do volume-based defences fail against it?

It exhausts the server's processing resources, such as processing time, memory, workers or backend queries, by sending valid requests that are cheap to generate but expensive to fulfil. Volume-based defences fail because the traffic is low in volume, normal in shape, and composed of legitimate-looking requests, so there is no flood, abnormal packet or saturated connection to detect.

1. What is a slow-request attack, and to which earlier attack is it analogous?

It sends or receives requests deliberately slowly so that the server keeps a connection and a worker occupied for a long time awaiting completion, exhausting the finite pool of workers with very little traffic and few connections. It is analogous to the SYN flood, which exhausts the connection backlog with half-open connections; here the exhaustion is of workers held by incomplete requests at the application level.

1. Why can a deliberately-slow password hash become a denial-of-service lever?

Because the slow hash that protects stored passwords costs the server meaningful processing per login attempt, so if login attempts are not rate-limited an attacker can trigger many of them cheaply and exhaust the server's processing. The protective cost of the hash, intended to slow attackers guessing offline, is turned against the server online unless login attempts are limited per source and per account.

1. Why is distinguishing this attack from legitimate use difficult, and what is needed to do it?

Because individual malicious requests are valid and resemble legitimate heavy use, such as a genuine user running an expensive report, so no single request is identifiably bad and blocking by rate risks legitimate users. Distinguishing requires context rather than the request alone: whether one source is making many disproportionately expensive requests, whether the pattern is automated, and whether the cost is out of proportion to any plausible need.

1. What is the general principle behind the defences, and give three concrete measures?

The principle is to make the application cost-aware, so that expensive work is bounded and, where possible, costs the attacker as much as the server, removing the asymmetry the attack exploits. Concrete measures include rate-limiting expensive operations per client, bounding those operations with required filters, pagination, result caps and timeouts, and enforcing timeouts on slow requests so incomplete requests cannot hold workers indefinitely.