Authentication (ATK)

Unlike other cards in this suit, this AT K relates to an attacker being able to change the executing code. This may be due to inadequate source code control, deployment controls or server protection, or compromise of delegated authentication, but could also be modification of client-side code. See AT J for missing authentication, AT Q for inconsistent authentication, and other cards in this suit for individual authentication issues (e.g. missing notification, inadequate password protection, enumeration, weak account management, weak use of temporary passwords, bypass, missing re-authetication, etc).

Scenario: Olga's Manipulation of Authentication Code

Visualize a scenario where Olga, exploiting vulnerabilities within a system, manages to alter or influence authentication code or routines, thereby bypassing security measures. She achieves this by:

1. Direct Manipulation of Authentication Code: Olga finds a way to access and modify the source code responsible for authentication.
2. Influencing Authentication Routines: She exploits weaknesses in the system to indirectly influence how authentication routines behave, leading to security lapses.

Example

Olga targets an application with inadequate security measures in its code deployment process. She injects malicious code into the authentication module during an update. This altered code introduces a backdoor that allows her to bypass normal authentication checks. Whenever she accesses the system, the modified code recognizes her specific input pattern and grants access without the need for legitimate credentials.

Threat Modeling

STRIDE

This scenario maps primarily to STRIDE: Tampering.

Tampering involves unauthorized modification of data or code. Olga alters the authentication module itself, changing how it behaves so she can bypass normal checks. The attack is not just exploiting weak authentication, it’s modifying the code that enforces authentication, which is classic integrity compromise, i.e., Tampering.

What can go wrong?

This form of attack can lead to unauthorized system access, data breaches, and potentially allow for widespread manipulation of system functions.

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?

In general, all authentication routines should be on the server-side using robust, tested and protected routines.

1. Implement strict access controls and security measures in the code development and deployment process to prevent unauthorized modifications.
2. Regularly review and audit authentication modules to detect any unauthorized changes or vulnerabilities.
3. Employ continuous monitoring tools to track and alert any unusual behavior within authentication routines.

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