Cryptography (CR3)

The key concept is that the absence of integrity checks allows attackers to tamper with data, code, and configurations without detection, compromising system trust and security.

Scenario: Axel's Data and Code Manipulation Due to Lack of Integrity Checks

Envision a situation where Axel manipulates various types of data and code within a system, exploiting the absence of integrity checking. This lack of verification allows for:

1. Alteration of Data in Transit or Storage: Axel can modify data being transmitted or stored, as there are no checks to validate data integrity.
2. Source Code Tampering: The source code, including updates and patches, can be altered without detection.
3. Configuration Data Changes: Axel can change configuration settings without triggering any alerts.

Example

Axel targets an application that does not implement integrity checks on its data transmissions. He intercepts data being sent to the server and modifies it, injecting malicious content or altering transaction details. Additionally, he tampers with source code updates before they are applied, introducing vulnerabilities into the system. The lack of integrity verification means these alterations go unnoticed and are executed as if legitimate.

Threat Modeling

STRIDE

The applicable STRIDE category for this scenario is Tampering.

Axel is modifying data, source code, updates, or configuration in a way that the system cannot detect because integrity checks are missing. The core threat is unauthorized alteration of information or code, which could lead to malicious execution or corruption.

What can go wrong?

The possibility for tampering with state, source code, interpreted code, libraries, executables, updates, patches, configuration data, logs, etc undermines any trust in the application. Consider the file system, database content, information in memory, in page code, and data in transit.

Such vulnerabilities can lead to unauthorized data manipulation, introduction of malware, corrupted system updates, and compromised system functionality.

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. Implement cryptographic hash functions and digital signatures to ensure data integrity for stored and in-transit data.
2. Apply integrity checks to source code, updates, patches, and configuration data, verifying their authenticity before acceptance and execution.
3. Regularly audit and update security protocols to maintain effective protection against data and code tampering.

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