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.
Potential Impact
Integrity, Other
Other
Non-Repudiation, Other
Hide Activities, Other
Demonstrative Examples
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);}Mitigations & Prevention
Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.
Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2025-32890 | Mesh device uses a cryptographic algorithm without integrity checking, allowing modification of messages |
Related Weaknesses
Taxonomy Mappings
- CLASP: — Failure to add integrity check value
- ISA/IEC 62443: Part 2-4 — Req SP.03.03 RE(1)
- ISA/IEC 62443: Part 2-4 — Req SP.04.02 RE(1)
- ISA/IEC 62443: Part 2-4 — Req SP.11.06 RE(2)
- ISA/IEC 62443: Part 3-3 — Req SR 3.1
- ISA/IEC 62443: Part 4-1 — Req SD-1
- ISA/IEC 62443: Part 4-2 — Req CR 3.1
Frequently Asked Questions
What is CWE-353?
CWE-353 (Missing Support for Integrity Check) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. 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.
How can CWE-353 be exploited?
Attackers can exploit CWE-353 (Missing Support for Integrity Check) to other. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-353?
Key mitigations include: Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.
What is the severity of CWE-353?
CWE-353 is classified as a Base-level weakness (Medium abstraction). It has been observed in 1 real-world CVEs.