T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:334- Finding
Non-Atomic Fixed-Window Rate Limiter Can Leave Persistent Keys
- Content
View full analysis
100: reject ``` ### Technical Analysis The counter increment and TTL assignment are performed as two independent Redis commands. Redis guarantees atomicity for each command, but not for the sequence as a whole. If the client crashes, disconnects, times out, or is terminated after `INCR` succeeds but before `EXPIRE` executes, the counter remains without an expiration. Because the key includes the minute, it may no longer participate in rate-limit decisions, but it remains stored indefinitely and consumes memory. The unconditional `EXPIRE` also refreshes the key's TTL on every request instead of assigning it only when the counter is first created. This makes the key lifecycle dependent on the most recent request rather than the intended fixed-window boundary. ### Attack Path 1. An attacker sends requests that create many distinct rate-limit keys, such as requests associated with numerous spoofable or attacker-controlled identifiers. 2. Each request causes the application to execute `INCR`. 3. The attacker exploits or amplifies connection instability, worker termination, timeouts, or service overload so that some executions stop before `EXPIRE`. 4. Successfully incremented keys from interrupted executions retain no TTL. 5. Repeating the process accumulates stale keys and increases Redis memory consumption. ### Impact Assessment This issue does not grant operating-system privileges or direct access to protected Redis data. Its scope is the Redis database used by the limiter. Potential impact includes: - Persistent accumulation of stale rate-limit keys - Increased Redis memory consumpti ...[truncated 257 chars]- Remediation
View remediation