CWE-297: Improper Validation of Certificate with Host Mismatch

Description:
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.

Extended Description:
Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the product is interacting with. In order to ensure data integrity, the certificate must be valid, and it must pertain to the site that is being accessed. 
             Even if the product attempts to check the hostname, it is still possible to incorrectly check the hostname. For example, attackers could create a certificate with a name that begins with a trusted name followed by a NUL byte, which could cause some string-based comparisons to only examine the portion that contains the trusted name.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Mobile, Web Based
Parent weaknesses: CWE-923, CWE-295

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Authentication: Other
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin
  - Dynamic Analysis with Manual Results Interpretation: Set up an untrusted endpoint (e.g. a server) with which the product will connect.  Create a test certificate that uses an invalid hostname but is signed by a trusted CA and provide this certificate fr
  - Black Box: When Certificate Pinning is being used in a mobile application, consider using a tool such as Spinner [REF-955].  This methodology might be extensible to other technologies.

Mitigations:
  - [Architecture and Design] Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed.
  - [Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

Demonstrative examples:
The following OpenSSL code obtains a certificate and verifies it.
Even though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.
cert = SSL_get_peer_certificate(ssl); if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) { 
                         
                            
                            // do secret things 
                            
                         
                      }

Real-world examples:
  - CVE-2012-5810: Mobile banking application does not verify hostname, leading to financial loss.
  - CVE-2012-5811: Mobile application for printing documents does not verify hostname, allowing attackers to read sensitive documents.
  - CVE-2012-5807: Software for electronic checking does not verify hostname, leading to financial loss.
  - CVE-2012-3446: Cloud-support library written in Python uses incorrect regular expression when matching hostname.
  - CVE-2009-2408: Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.