A08:2021 - Software and Data Integrity Failures
Celia Catalán
Vulnerability Description
This type of vulnerability manifests when the application is not adequately protected against the manipulation of critical data or software components, which can lead to alterations in data, spoofing attacks, or the injection of unauthorized code. This category specifically includes risks such as the lack of integrity in software updates, external libraries, or critical data configurations.
Impact
The impact of this vulnerability on the systems and applications where it is present includes the following:
- Code injections: Attackers can compromise software and applications by injecting code that runs on the system. This could result in unauthorized access, data leakage, or alteration of the system's functionality.
- Software Supply Chain Commitment: If an attacker manages to compromise a dependency or library used by multiple organizations, the impact can be widespread, affecting numerous applications that rely on that component.
- Privilege escalation or denial of service attacks: It is possible to modify critical system configurations or introduce vulnerabilities that allow privilege escalation, compromising the infrastructure or preventing its proper functioning.
Relationship with other vulnerabilities of OWASP Top Ten
- A06:2021 - Vulnerable and Outdated Components: This vulnerability is closely related to the use of insecure or outdated components, as the lack of software integrity often involves vulnerable dependencies.
- A07:2021 - Identification and Authentication Failures: If authentication configurations are not adequately protected, attackers can exploit data integrity failures to manipulate these mechanisms.
- A09:2021 - Security Logging and Monitoring Failures: The lack of adequate monitoring can allow errors in software or data integrity to go unnoticed, increasing the risk of exploitation.
Practical example
Insecure Deserialization
Insecure deserialization occurs when a website deserializes user-controlled data. This can allow an attacker to manipulate serialized objects to introduce malicious data into the application code.
In some cases, the attacker can replace a serialized object with one from a completely different class. The concerning part is that any object from a class available on the website will be deserialized and instantiated, regardless of the class that was originally expected. For this reason, insecure deserialization is also known as an "object injection" vulnerability.
"An object of an unexpected class could generate an exception, but in many cases, the damage may have already occurred. In fact, many deserialization-based attacks are completed before the process finishes. This means that the deserialization process itself can trigger the attack, even if the website's functionality does not directly interact with the malicious object. Therefore, websites that use strictly typed languages can also be vulnerable to these techniques."
Manipulation of serialized objects
Exploiting some deserialization vulnerabilities can be as simple as modifying an attribute in a serialized object. Since the state of the object is preserved, it is possible to analyze the serialized data to identify and change the values of relevant attributes. Then, the malicious object can be sent to the website through its deserialization process. This is the initial step in a basic deserialization attack.
In general terms, there are two approaches to manipulating serialized objects. One can edit the object directly in its byte stream form, or write a small script in the corresponding language to create and serialize the new object on one's own. The latter approach is often simpler when working with binary serialization formats.
Modification of the attributes of serialized objects
By manipulating the data, as long as the attacker retains a valid serialized object, the deserialization process will create an object on the server with the modified attribute values.
As an example, a website is accessed with valid non-privileged user credentials and the website generates a session cookie, as can be seen in the following image:
Mitigations
- Use digital signatures or similar mechanisms to verify that the software or data comes from the original source and has not been altered.
- It is necessary to ensure that libraries and dependencies, such as npm or Maven, are obtained from trusted repositories. If the application has a high-risk profile, it may be considered to host a trusted internal repository.
- Use security tools for the software supply chain, such as OWASP Dependency Check or OWASP CycloneDX, to verify that the components do not contain known vulnerabilities.
- Establish a process for reviewing changes in code and configuration to minimize the possibility of introducing malicious code or configurations into the pipeline.
- Ensure that the CI/CD pipeline has appropriate segregation, configuration, and access control to guarantee the integrity of the code flowing through the build and deployment processes.
- Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect manipulation or reproduction of the serialized data.
