Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%

CWE-353 (缺失完整性检查支持) — Vulnerability Class 32

32 vulnerabilities classified as CWE-353 (缺失完整性检查支持). AI Chinese analysis included.

CWE-353 represents a critical architectural weakness where software relies on transmission protocols lacking built-in integrity verification mechanisms, such as checksums or cryptographic hashes. This omission leaves data vulnerable to undetected corruption or malicious tampering during transit, as the application cannot distinguish between legitimate transmission errors and intentional alterations by an attacker. Exploitation typically involves intercepting and modifying data packets in transit, allowing adversaries to inject malicious payloads or alter critical information without triggering immediate detection by the receiving system. To mitigate this risk, developers must implement robust integrity checks at the application layer, utilizing algorithms like HMAC or SHA-256 to validate data authenticity. Additionally, employing secure transport protocols such as TLS ensures that data remains both encrypted and integrity-protected throughout the communication process, effectively closing this security gap.

MITRE CWE Description
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum. If integrity check values or "checksums" are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol's checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.
Common Consequences (2)
Integrity, OtherOther
Data that is parsed and used may be corrupted.
Non-Repudiation, OtherHide Activities, Other
Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.
Mitigations (2)
Architecture and DesignAdd an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.
ImplementationEnsure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.
Examples (1)
In this example, a request packet is received, and privileged information is sent to the requester:
while(true) { DatagramPacket rp = new DatagramPacket(rData,rData.length); outSock.receive(rp); InetAddress IPAddress = rp.getAddress(); int port = rp.getPort(); out = secret.getBytes(); DatagramPacket sp =new DatagramPacket(out, out.length, IPAddress, port); outSock.send(sp); }
Bad · Java
CVE IDTitleCVSSSeverityPublished
CVE-2019-10943 多款Siemens产品数据伪造问题漏洞 — SIMATIC Drive Controller family--2019-08-13
CVE-2019-12804 Hunesion i-oneNet Missing Support for Integrity Check vulnerability — i-oneNet 5.5 -2019-07-10

Vulnerabilities classified as CWE-353 (缺失完整性检查支持) represent 32 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.