The system must guarantee that objects (session id, cookies, etc.) used in the authentication process cannot be reused (replay resistance).
In a system, it is necessary to prevent transmitted information from being reused by an attacker to impersonate an authorized user or server responses. Therefore, it is essential to verify the communications between the users and the system, thus avoiding a replay of any request that could affect the confidentiality, integrity and/or availability of the system.
In order to prevent this type of impersonation, there are several options to consider depending on the context and implementation method. Some good practices to avoid data reutilization are listed below:
Cryptographic nonce: It consists of numbers that expire after their first use or after a small lapse of time, and through which the authenticity of a message can be verified. They are often randomized and used in authentication protocols to ensure that past communications cannot be reused.
Timestamping: In order to implement this method, there must be a clock synchronization between the client and the server. The server will only accept messages with a date and time within a defined tolerance range. Thus, it minimizes the risk of potential attacks by significantly limiting the time windows for exploitation.
Session Token: In this method, the server sends a token code which is used by the client to transform a key (e.g., applying hash functions to the key and token combination) before sending it again to the server as part of the authentication process. The server then processes this value, compares it with the initial token, and rejects the request if they do not match. Thus, an attacker cannot perform replay attacks because the token sent by the server will be different (token generation must be random).
Session Time-out: Session objects are invalidated when the user terminates a session or when the user surpasses a certain time limit without posting new requests.
- Session hijacking
- Identity impersonation
- Man in the middle (MitM)
- Replay attack
- Layer: Application layer
- Asset: Session management
- Scope: Authenticity
- Phase: Construction
- Type of control: Recommendation
CAPEC-60: Reusing Session IDs (aka Session Replay): This attack targets the reuse of a valid session ID to spoof the target system in order to gain privileges.
CWE-287: Improper Authentication: When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.
CWE-294: Authentication Bypass by Capture-replay: A capture-replay flaw exists when the design of the software makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
CWE-308: Use of Single-factor Authentication: The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
CWE-345: Insufficient Verification of Data Authenticity: The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
ISO 27001:2013. Annex A - 14.1.3: Protect information included in application services transactions to avoid partial transmission, improper routing, unauthorized message modifications, unauthorized disclosure and unauthorized message duplication or replay.
NIST 800-63B 5.2.8 Replay Resistance: An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.
NIST 800-63B 7.1 Session Bindings: Secrets used for session binding SHALL be generated by the session host during an interaction, typically immediately following authentication.
OWASP Top 10 A2:2017-Broken Authentication: Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.
OWASP-ASVS v4.0.1 V2.2 General Authenticator Requirements.(2.2.6): Verify replay resistance through the mandated use of OTP devices, cryptographic authenticators, or lookup codes.
OWASP-ASVS v4.0.1 V3.2 Session Binding Requirements.(3.2.1): Verify the application generates a new session token on user authentication.
PCI DSS v3.2.1 - Requirement 6.5.10: Address common coding vulnerabilities in software-development processes such as broken authentication and session management.