Difference between revisions of "Failure to check integrity check value"

From OWASP
Jump to: navigation, search
 
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
  
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
{{Template:SecureSoftware}}
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Overview==
+
==Description==
  
 
If integrity check values or "checksums" are not validated before messages are parsed and used, there is no way of determining if data has been corrupted in transmission.
 
If integrity check values or "checksums" are not validated before messages are parsed and used, there is no way of determining if data has been corrupted in transmission.
  
==Consequences ==
+
'''Consequences'''
  
* Authentication: Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.
+
* Authentication: Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.
 +
* Integrity: Data that is parsed and used may be corrupted.
 +
* Non-repudiation: Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.
  
* Integrity: Data that is parsed and used may be corrupted.
+
'''Exposure period'''
  
* Non-repudiation: Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.
+
* Implementation: Checksums must be properly checked and validated in the implementation of message receiving.  
  
==Exposure period ==
+
'''Platform'''
  
* Implementation: Checksums must be properly checked and validated in the implementation of message receiving.
+
* Languages: All
 +
* Operating platforms: All
  
==Platform ==
+
'''Required resources'''
 
+
* Languages: All
+
 
+
* Operating platforms: All
+
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood  of exploit ==
+
'''Likelihood  of exploit'''
  
 
Medium
 
Medium
  
==Avoidance and mitigation ==
+
The failure to validate checksums before use results in an unnecessary risk that can easily be mitigated with very few lines of code. Since the protocol specification describes the algorithm used for calculating the checksum, it is a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match.
  
* Implementation: Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.  
+
If this small amount of effort is skipped, the consequences may be far greater.
  
==Discussion ==
 
  
The failure to validate checksums before use results in an unnecessary risk that can easily be mitigated with very few lines of code. Since the protocol specification describes the algorithm used for calculating the checksum, it is a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match.
+
==Risk Factors==
 +
 
 +
TBD
  
If this small amount of effort is skipped, the consequences may be far greater.
 
  
==Examples ==
+
==Examples==
  
 
In C/C++:
 
In C/C++:
  
 +
<pre>
 
sd = socket(AF_INET, SOCK_DGRAM, 0);
 
sd = socket(AF_INET, SOCK_DGRAM, 0);
 
serv.sin_family = AF_INET;
 
serv.sin_family = AF_INET;
Line 63: Line 64:
 
               (struct sockaddr *) & cli, &clilen);
 
               (struct sockaddr *) & cli, &clilen);
 
}
 
}
 +
</pre>
 +
 
In Java:
 
In Java:
  
 +
<pre>
 
while(true) {
 
while(true) {
 
   DatagramPacket packet  
 
   DatagramPacket packet  
Line 70: Line 74:
 
   socket.send(sendPacket);
 
   socket.send(sendPacket);
 
}
 
}
==Related problems ==
+
</pre>
  
* Failure to add integrity check value
 
  
==Categories ==
+
==Related [[Attacks]]==
  
[[Category:Vulnerability]]
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
 +
 +
==Related [[Vulnerabilities]]==
 +
 +
* [[Failure to add integrity check value]]
 +
 +
==Related [[Controls]]==
 +
 +
* Implementation: Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.
 +
 +
==Related [[Technical Impacts]]==
 +
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
TBD
 +
 +
[[Category:FIXME|add links
 +
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 +
Availability Vulnerability
 +
 +
Authorization Vulnerability
 +
 +
Authentication Vulnerability
 +
 +
Concurrency Vulnerability
 +
 +
Configuration Vulnerability
 +
 +
Cryptographic Vulnerability
 +
 +
Encoding Vulnerability
 +
 +
Error Handling Vulnerability
 +
 +
Input Validation Vulnerability
 +
 +
Logging and Auditing Vulnerability
 +
 +
Session Management Vulnerability]]
 +
 +
__NOTOC__
 +
 +
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 
[[Category:Protocol Errors]]
 
[[Category:Protocol Errors]]
 +
[[Category:OWASP_CLASP_Project]]

Latest revision as of 19:42, 20 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

If integrity check values or "checksums" are not validated before messages are parsed and used, there is no way of determining if data has been corrupted in transmission.

Consequences

  • Authentication: Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.
  • Integrity: Data that is parsed and used may be corrupted.
  • Non-repudiation: Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.

Exposure period

  • Implementation: Checksums must be properly checked and validated in the implementation of message receiving.

Platform

  • Languages: All
  • Operating platforms: All

Required resources

Any

Severity

High

Likelihood of exploit

Medium

The failure to validate checksums before use results in an unnecessary risk that can easily be mitigated with very few lines of code. Since the protocol specification describes the algorithm used for calculating the checksum, it is a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match.

If this small amount of effort is skipped, the consequences may be far greater.


Risk Factors

TBD


Examples

In C/C++:

sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));
while (1) {
  memset(msg, 0x0, MAX_MSG);
  clilen = sizeof(cli);
  if (inet_ntoa(cli.sin_addr)==...)
  n = recvfrom(sd, msg, MAX_MSG, 0,
              (struct sockaddr *) & cli, &clilen);
}

In Java:

while(true) {
  DatagramPacket packet 
    = new DatagramPacket(data,data.length,IPAddress, port);
  socket.send(sendPacket);
}


Related Attacks


Related Vulnerabilities

Related Controls

  • Implementation: Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

Related Technical Impacts


References

TBD