Sandwich Attack

What Is a Sandwich Attack?

A sandwich attack is an application security technique where an attacker predicts a target’s time-based token by bracketing the victim’s request between two attacker-controlled requests with known timestamps. By generating tokens immediately before and after the target’s request, the attacker narrows the range of possible token values to a brute-forceable window.

Sandwich attacks target application security vulnerabilities in password reset flows, account verification mechanisms, and any process that issues tokens derived from predictable inputs like time-based UUIDs. When successful, a sandwich attack leads directly to account takeover without requiring the attacker to intercept network traffic or compromise the user’s email.

How Time-Based UUID Tokens Enable Sandwich Attacks

The core vulnerability lies in how applications generate tokens. Many systems use UUIDv1, which incorporates a timestamp, clock sequence, and MAC address into the token’s structure. Because the timestamp component is derived from the system clock at the moment of generation, it is predictable.

In a time-based token attack, the attacker triggers their own token generation requests (for example, password reset requests for their own accounts) immediately before and after the victim’s token is generated. The attacker now has two known tokens whose timestamps bracket the victim’s token. The unknown portion, the time delta between the attacker’s two requests, is small enough to enumerate.

UUID token prediction becomes practical when the attacker can generate requests in rapid succession and the server’s token generation has low latency. If the attacker’s two requests are 50 milliseconds apart, the possible timestamp values for the victim’s token are constrained to that window, reducing the search space dramatically.

UUIDv1 vs. UUIDv4: Why Randomness Matters for Security

The distinction between UUID versions is central to understanding sandwich attack risk.

UUIDv1 was designed for uniqueness, not unpredictability. Its structure encodes the exact time of creation, making it fundamentally unsuitable for security-sensitive token generation. UUIDv4 generates tokens from a cryptographically secure random number generator, producing 2^122 possible values that cannot be narrowed through timing analysis.

Any vulnerability discovery process should flag UUIDv1 usage in authentication and token generation contexts as a high-priority finding.

Step-by-Step: How a Sandwich Attack Leads to Account Takeover

A typical sandwich attack against a password reset vulnerability follows this sequence.

The attacker identifies that the target application uses UUIDv1 tokens for password reset links. They request a password reset for their own account (Account A), generating Token A with a known timestamp. Immediately after, they trigger a reset for the victim’s account, then immediately request another reset for a second controlled account (Account B), generating Token B.

Token A and Token B now bracket the victim’s token in time. The attacker enumerates all possible UUIDv1 values between the two timestamps, testing each candidate against the reset endpoint. When the correct token is found, the attacker sets a new password and achieves account takeover.

The entire attack can complete in seconds when the time window is narrow and the application does not rate-limit reset token validation attempts.

How to Prevent Sandwich Attacks in Authentication Flows

Preventing sandwich attacks requires addressing both token generation and token validation. Broken access control patterns in reset flows compound the risk, so defenses should be layered.

• Use UUIDv4 or cryptographically random tokens: Replace UUIDv1 with UUIDv4 or tokens from a cryptographically secure random number generator (CSPRNG). This eliminates the timing-based predictability that sandwich attacks exploit.
• Token expiration: Set short expiration windows (15 minutes or less) for password reset tokens to limit enumeration time.
• Rate limiting on token validation: Limit reset token validation attempts per IP and per account. A token brute force attack becomes infeasible when the application blocks rapid sequential attempts.
• One-time use tokens: Invalidate tokens after first use or after a new token is generated for the same account.
• Server-side validation: Store reset tokens server-side with associated metadata (user ID, creation time, IP) rather than embedding all context in the token.

Static application security testing tools can detect UUIDv1 usage in token generation code paths, flagging insecure patterns during code review before they reach production.

FAQs

What makes UUIDv1 tokens predictable compared to UUIDv4?

UUIDv1 embeds a timestamp and MAC address, making values derivable from known timing. UUIDv4 uses 122 bits of cryptographic randomness, producing tokens that cannot be predicted through timing analysis.

Can a sandwich attack succeed if the attacker does not know the exact timestamp of the target’s token request?

Yes. The attacker brackets the victim’s request with their own, constraining the victim’s token to the time window between the two known tokens rather than needing the exact timestamp.

Which password reset and token generation patterns are most commonly exploited in sandwich attacks?

Systems using UUIDv1, sequential timestamps, or insufficiently random token generators for password reset vulnerability flows are the primary targets, especially when combined with unlimited validation attempts.

How can developers validate that their token generation is cryptographically random?

Use language-native CSPRNGs (secrets module in Python, SecureRandom in Java, crypto.randomBytes in Node.js) and verify through code review that no predictable seed or time-based input feeds the generator.

Does rate limiting protect against sandwich attacks, or are additional controls needed?

Rate limiting slows enumeration but does not address the root cause. Combining rate limiting with cryptographically random tokens, short expiration, and one-time use provides comprehensive protection.