Missing Support for Integrity Check

Draft Base
Structure: Simple
Description

This vulnerability occurs when a system uses a communication protocol that lacks built-in integrity verification, such as a checksum or cryptographic hash, to detect if data has been altered or corrupted during transmission.

Extended Description

When a protocol doesn't include integrity checks like checksums, there's no reliable way for the receiving end to know if the data arrived exactly as it was sent. Corruption from network errors, hardware faults, or even malicious tampering can go undetected. This missing layer of validation means corrupted data is passed directly to the application, which must then bear the full responsibility for detecting these errors—if it can at all. The principle of end-to-end integrity argues that verification should happen at the lowest protocol layer where it can be fully implemented. A protocol-level checksum is the most effective guard because it validates an entire message or session, not just individual network packets. While applications should still perform their own input validation, relying solely on that is riskier and less efficient than having the underlying communication channel guarantee data integrity from the start.

Common Consequences 2
Scope: IntegrityOther

Impact: Other

Data that is parsed and used may be corrupted.

Scope: Non-RepudiationOther

Impact: Hide ActivitiesOther

Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.

Potential Mitigations 2
Phase: Architecture and Design
Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.
Phase: Implementation
Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.
Demonstrative Examples 1
In this example, a request packet is received, and privileged information is sent to the requester:

Code Example:

Bad
Java
java
The response containing secret data has no integrity check associated with it, allowing an attacker to alter the message without detection.
References 2
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
Likelihood of Exploit

Medium

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Taxonomy Mapping
  • CLASP
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443