This weakness occurs when software responds to incoming network requests by generating disproportionately large or numerous outbound messages without proper…
This weakness occurs when software responds to incoming network requests by generating disproportionately large or numerous outbound messages without proper limits. An attacker can exploit this to amplify their traffic, overwhelming a target system or network. Unlike direct denial-of-service attacks, amplification attacks use a vulnerable intermediary to multiply the attacker's bandwidth, making them particularly dangerous at scale.
The vulnerability arises when a service accepts a small request and generates a much larger response without validating the request source or limiting response volume. Common patterns include:
- Reflection without rate-limiting:
A service echoes back user input or generates responses proportional to input size without checking how many requests come from the same source.
- Stateless amplification:
Services that respond to every request identically (e.g., DNS queries, NTP responses) without tracking or throttling per-client traffic.
- Unvalidated request routing:
Systems that forward or relay messages without confirming the request origin, allowing attackers to spoof source addresses and redirect responses to victims.
- Unbounded response generation:
APIs or protocols that generate responses whose size scales with input parameters, with no upper bound enforced.
The attacker sends a small, spoofed request to the vulnerable service; the service responds with a large message directed at the victim's address, multiplying the attacker's effective bandwidth.
Amplification attacks can saturate network links and exhaust server resources at the target, causing service unavailability. Because the attacker's traffic is small and the responses are large, detection and mitigation are harder — the victim sees traffic from many sources (the amplifiers), not directly from the attacker. This has historically affected DNS servers, NTP services, and other stateless protocols, resulting in multi-gigabit-per-second attacks against high-profile targets.
import socket
def handle_request(data, client_addr):
# Attacker sends small request; service generates large response
query = data.decode().strip()
# Response size scales with input, no limit
response = "RESPONSE: " + query * 1000
# No validation of client_addr; response sent to any address
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(response.encode(), client_addr)Why it's vulnerable:
The response size grows unbounded with input, and the service sends responses to any address without validating the request source. An attacker can spoof the source address to redirect large responses to a victim.
import socket
from collections import defaultdict
import time
request_log = defaultdict(list)
MAX_REQUESTS_PER_SECOND = 10
MAX_RESPONSE_SIZE = 512
def handle_request(data, client_addr):
# Rate-limit per source address
now = time.time()
request_log[client_addr] = [t for t in request_log[client_addr] if now - t < 1]
if len(request_log[client_addr]) >= MAX_REQUESTS_PER_SECOND:
return # Drop request
request_log[client_addr].append(now)
query = data.decode().strip()
# Cap response size
response = ("RESPONSE: " + query)[:MAX_RESPONSE_SIZE]
# Only respond to legitimate, non-spoofed requests (e.g., via TCP or validated source)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(response.encode(), client_addr)<?php
// Receives a query parameter and echoes it back with amplification
$user_input = $_GET['query'] ?? '';
// Response size scales with input, no limit
$response = "RESULT: " . str_repeat($user_input, 500);
// Send response to any address (if using UDP or similar)
// In a real scenario, this might be a DNS or NTP-like service
echo $response;
?>Why it's vulnerable:
The response grows proportionally to user input with no size cap, and the service responds to every request without rate-limiting or source validation.
<?php
// Rate-limit and cap response size
$max_response_size = 512;
$max_requests_per_second = 10;
$client_ip = $_SERVER['REMOTE_ADDR'];
// Simple in-memory rate-limit (use Redis or similar in production)
$cache_key = "requests_" . $client_ip;
$request_count = apcu_fetch($cache_key) ?: 0;
if ($request_count >= $max_requests_per_second) {
http_response_code(429);
exit("Rate limit exceeded");
}
apcu_store($cache_key, $request_count + 1, 1);
$user_input = $_GET['query'] ?? '';
// Cap response size and limit repetition
$response = "RESULT: " . substr($user_input, 0, 50);
// Validate request legitimacy (e.g., require a token, use TCP only)
if (strlen($response) > $max_response_size) {
$response = substr($response, 0, $max_response_size);
}
echo $response;
?>Monitor your network for sudden spikes in outbound traffic, especially if it correlates with inbound requests from many different sources. Check server logs for patterns of small requests followed by large responses. If your service is listed in public amplification registries or you receive complaints from third parties about traffic originating from your IP addresses, investigate whether your systems are being used as amplifiers.
