The absence of replay attack defenses allows identical repeated interactions to be accepted as new, enabling attackers to tamper with system state and trigger unauthorized actions.

Scenario: Jeff’s Replay Attack Exploitation

Consider a scenario where Jeff exploits a system vulnerability that allows him to reuse stolen session identifiers or tokens without any checks for their validity or proof of possession. This issue arises because the system does not have mechanisms to detect and reject forged or replayed session identifiers or tokens, allowing attackers to reuse them for unauthorized access or actions.

1. Lack of Confidential Handling: Session identifiers or tokens are not treated as sensitive information, leading to their exposure and potential theft.
2. Absence of Proof of Possession: The system does not require any form of proof that the session identifier or token is being used by the legitimate owner, such as mTLS sender-constrained tokens, DPoP, or token binding/device-bound credentials.
3. No Detection of Reuse: The system does not have mechanisms to detect and reject replayed session identifiers or tokens, allowing attackers to reuse them for unauthorized access or actions.

Example

Jeff observes an online transaction process where a user submits a payment form. He captures the HTTP request of this transaction and later resends the exact same request multiple times. The system, lacking checks for proof of possession and replay detection, processes each request as if it were a valid transaction, allowing Jeff to execute multiple unauthorized transactions using the same session identifier or token.

Threat Modeling

STRIDE

This scenario maps primarily to STRIDE: Spoofing.

Spoofing is about impersonating a legitimate user or entity. Jeff observes an online transaction process where a user submits a request and resends an identical request (a replay attack) and the system accepts it (e.g., triggering multiple transactions) as if Jeff were somebody else. The attack is about impersonation, but may lead to unauthorized manipulation of data/state, Tampering and even Elevation of Privilege.

What can go wrong?

Such vulnerabilities can lead to replay attacks, resulting in unauthorized transactions, data breaches, and exploitation of system functionalities.

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

1. Treat session identifiers and tokens as sensitive information, ensuring they are handled confidentially and securely.
2. Implement proof of possession mechanisms, such as mTLS sender-constrained tokens, DPoP, or token binding/device-bound credentials to ensure that they can only be used by the legitimate owner.
3. Implement mechanisms to detect and reject replayed session identifiers or tokens, such as using nonces, timestamps, or maintaining a list of recently used identifiers/tokens to prevent their reuse.
4. Consider implementing additional security measures such as multi-factor authentication, anomaly detection, and rate limiting to further protect against replay attacks.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.