32.2.3 Sliding window manipulation

While a fixed-window rate limiter resets its counter at discrete intervals (e.g., at the start of every minute), a sliding window offers a more robust defense by continuously evaluating the request count over the most recent time period. This prevents the classic “edge burst” attack where an attacker sends a full quota of requests at the end of one window and another full quota at the start of the next. However, this more sophisticated defense introduces a new, more subtle attack surface: the window’s boundary logic.

Understanding the Sliding Window Mechanism

A sliding window rate limiter doesn’t care about the absolute start or end of a minute. It only cares about the last `N` seconds. If the limit is 100 requests per minute, the system constantly asks, “How many requests have I seen in the last 60 seconds?” As time moves forward, older requests “slide” out of this window of consideration, making room for new ones.

The effectiveness of this mechanism depends heavily on its granularity. A window might be implemented as a single counter that is updated every second, or as a series of smaller time-slice counters that are aggregated. This implementation detail is precisely what an attacker seeks to exploit.

Attack Vector: Probing and Synchronizing with Window Expiration

The core of this attack is to stop thinking about the rate limit as a broad rule and start thinking of it as a state machine with predictable transitions. Your goal is to reverse-engineer the window’s duration and its refresh cadence, allowing you to synchronize your requests with the exact moment old requests expire.

1. Phase 1: Saturation and Probing. The first step is to map the target’s behavior.
   • Send a rapid burst of requests to intentionally hit the rate limit. Note the exact timestamp of each request.
   • Wait for a short, calculated period (e.g., half the suspected window duration).
   • Begin sending single “probe” requests at a slow, steady interval (e.g., one per second).
   • The moment a probe request succeeds, you have discovered the window’s duration. The time elapsed between the first request in your initial burst and the first successful probe is the window size.
2. Phase 2: Synchronized Burst Execution. With the window duration known, you can execute a far more intelligent attack.
   • Send a burst of `N-1` requests, where `N` is the rate limit threshold.
   • Wait for the exact duration of the window, minus a small safety margin (to account for network latency).
   • As soon as the first requests from your previous burst are set to expire, you can send another burst. You are effectively “refilling” your quota the instant it becomes available, allowing you to maintain a consistently higher throughput than the system designers intended.

This transforms a brute-force problem into a precision timing attack. You are no longer guessing; you are exploiting the deterministic nature of the rate-limiting algorithm.

Code Example: Probing for Window Expiration

The following pseudocode illustrates the logic for determining a sliding window’s duration. This is a reconnaissance step crucial for planning the main attack.

# Pseudocode for window duration discovery
import time

TARGET_API = "https://api.example.com/v1/model"
RATE_LIMIT = 100 # Assumed limit from documentation or initial tests

def send_request(api_endpoint):
    # Sends a request and returns True for success (HTTP 200)
    # or False for rate limited (HTTP 429)
    response = http.post(api_endpoint)
    return response.status_code == 200

# Phase 1: Saturate the window
burst_timestamps = []
for i in range(RATE_LIMIT):
    send_request(TARGET_API)
    burst_timestamps.append(time.time())

first_request_time = burst_timestamps[0]
print(f"Sent initial burst of {RATE_LIMIT} requests.")

# Phase 2: Probe for the first opening
while True:
    time.sleep(0.5) # Probe every 500ms
    if send_request(TARGET_API):
        probe_success_time = time.time()
        window_duration = probe_success_time - first_request_time
        print(f"Probe successful! Estimated window duration: {window_duration:.2f} seconds.")
        break

Defensive Strategies and Mitigation

Defending against sliding window manipulation requires hardening the implementation of the rate-limiting logic itself. The goal is to make the window’s behavior less predictable and more resilient to precision timing.

Ultimately, sliding window manipulation is a testament to the fact that in security, implementation details are paramount. A conceptually strong defense can be undermined by a predictable and exploitable implementation. As a red teamer, your task is to find these subtle gaps in temporal logic and demonstrate their impact before a real adversary does.