Understanding Replay Attacks in Software Systems and How to Prevent Them

1. Simple Definition

A replay attack occurs when an attacker captures a legitimate network request packet and resends it multiple times without modification, tricking the server into repeating the operation. The key difference from tampering attacks is that the packet remains unchanged and valid.

2. Core Application Scenarios (High‑frequency in real software)

Payment interfaces (most critical)

Order submission and coupon redemption

Transfer and recharge operations

Voting, sign‑in activities

SMS delivery and points exchange

Third‑party API integrations

3. Two Complete Practical Examples

Example 1: Payment Scenario (Classic)

Normal flow: User places an order → sends payment request (orderNo=001, amount=199) → server deducts funds successfully.

Attack process:

The attacker uses a packet‑capture tool to obtain the successful payment HTTP request.

Without changing any parameters, they repeatedly click “Resend packet”.

The server receives identical payment requests, deducts money again, and creates new orders.

Result: The user is charged multiple times and the platform suffers financial loss. Many third‑party payment services (WeChat/Alipay) have built‑in replay protection, but internal APIs without safeguards are vulnerable.

Example 2: Coupon Redemption

Normal: Coupon 0088 can be redeemed once and then becomes invalid.

Attack: The attacker captures the redemption request and repeatedly submits it. Without replay detection, the same coupon is redeemed indefinitely, allowing unlimited discount extraction.

Common misconception: Relying solely on a unique order‑number constraint in the database solves only part of the problem. Interfaces without a unique order number—such as query, sign‑in, or voting APIs—remain exploitable.

4. Conditions Required for an Attacker

The request can be captured (HTTP is most vulnerable; HTTPS can still be captured locally).

The server lacks any mechanism to recognize duplicate submissions.

The request has no inherent expiration, allowing old packets to be processed at any time.

5. Four Main Industry Mitigation Solutions (From Simple to Standard)

Solution 1: Business‑Level Unique Transaction ID

Generate a globally unique identifier for each legitimate operation and store it (e.g., in Redis or a database). Before processing, check whether the ID has already been handled; if so, reject the request.

Example: create tradeNo=2026072215200001 for an order, require the client to send this tradeNo with the payment request, and verify its uniqueness.

Pros: Simple and easy to implement. Suitable for workflows where a transaction ID can be generated beforehand (order creation, payment, coupon redemption). Not suitable for ad‑hoc queries or sign‑in interfaces that lack a pre‑generated ID.

Solution 2: Timestamp + Valid Time Window

Include a current timestamp in the request (e.g., timestamp=1784782111). The server compares it with its own time and rejects requests whose timestamps differ by more than a configured window (commonly 5 minutes).

Effect: Old captured packets become invalid after the window expires. Limitation: Cannot stop rapid replay within the window, so this method is usually combined with other techniques.

Solution 3: One‑Time Random String (nonce)

Each request carries a unique, single‑use random string (nonce), often a UUID.

Client generates nonce=UUID for every request.

Request includes nonce and timestamp.

Server first validates the timestamp window.

Then checks Redis for the nonce’s existence.

If absent, the request proceeds and the nonce is stored in Redis with an expiration matching the timestamp window.

If the nonce already exists, the request is identified as a replay and rejected.

Industry‑standard practice: combine timestamp + nonce for external APIs and open platforms.

Solution 4: Signature Mechanism (Often Paired with nonce + timestamp)

Construct a signature using timestamp, nonce, business parameters, and a shared secret key, then apply SHA‑256. The server recomputes the signature and verifies it.

Benefits: Prevents replay attacks and also guards against man‑in‑the‑middle tampering.

6. Complete Standard Request Model (Common Template for Public APIs)

Request payload example:

{
  "bizData": "business parameters",
  "timestamp": 1784782500,
  "nonce": "uuid‑random‑string",
  "sign": "SHA256 signature"
}

Server validation order (must not be reordered):

Validate timestamp; reject if outside the 5‑minute window.

Validate the sign; reject if invalid (prevents tampering).

Check Redis for existing nonce; if found, treat as replay and reject.

If all checks pass, execute business logic and store the nonce with expiration.

7. Common Pitfalls Developers Encounter

Misconception: HTTPS eliminates replay attacks. Reality: HTTPS only encrypts transmission; local capture of HTTPS traffic is still possible.

Misconception: Front‑end button disabling prevents replay. Reality: Attackers can bypass UI restrictions by directly calling the API.

Misconception: Relying solely on a database unique index. Reality: Works only for flows with a unique order number; ineffective for sign‑in, voting, or query interfaces.

Misconception: Using only a timestamp without a nonce. Reality: Within the allowed window, attackers can resend the same request indefinitely.

8. One‑Sentence Summary

Replay attack = repeated submission of a legitimate old packet; the standard defense formula is timestamp (expire old packets) + nonce (prevent short‑term repeats) + signature (prevent tampering).