R030. Avoid object reutilization

Requirement

The system must guarantee that objects (session id, cookies, etc.) used in the authentication process can not be reused (replay resistance).

Description

In a system, it is necessary to prevent transmitted information from being reused by an attacker to impersonate an authorized user or server responses. Thus, it is essential to verify the communications between the users and the system, avoiding in this way a replay of any request that could affect the confidentiality, integrity and/or availability of the system.

Implementation

In order to prevent this type of impersonation, there are several options to considerate depending on the context and implementation method. Some good practices to avoid data reutilization are listed below:

  1. Cryptographic nonce: It consists of numbers that expire after their first use or after a small lapse of time, with which the authenticity of a message can be verified. They are often randomized and used in authentication protocols to ensure that past communications can not be reused.

  2. 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 an hour within a tolerance range. Thus, it minimizes the risk of potential attacks by providing small time windows for exploitation.

  3. 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).

  4. 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.

Attacks

  1. Session hijacking

  2. Identity impersonation

  3. Man in the middle (MitM).

  4. Replay attack

Attributes

  1. Layer: Application Layer

  2. Asset: Session management

  3. Scope: Authenticity

  4. Phase: Construction

  5. Type of Control: Recommendation

References

  1. 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.

  2. 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.

  3. 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).

  4. 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.

  5. 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.

  6. HTTP Authentication: Basic and Digest Access Authentication.

  7. 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.

  8. 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.

  9. 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.

  10. OWASP-ASVS v4.0.1 V3.2 Session Binding Requirements.(3.2.1) Verify the application generates a new session token on user authentication.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy