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.
View on MITREEven 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. If the certificate's host-specific data is not properly checked - such as the Common Name (CN) in the Subject or the Subject Alternative Name (SAN) extension of an X.509 certificate - it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host. 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. This weakness can occur even when the product uses Certificate Pinning, if the product does not verify the hostname at the time a certificate is pinned.
The data read from the system vouched for by the certificate may not be from the expected system.
Trust afforded to the system in question - based on the malicious certificate - may allow for spoofing or redirection attacks.
Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed.
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.
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 from the untrusted endpoint. If the product performs any operations instead of disconnecting and reporting an error, then this indicates that the hostname is not being checked and the test certificate has been accepted.
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.
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.
Mobile banking application does not verify hostname, leading to financial loss.
View DetailsMobile application for printing documents does not verify hostname, allowing attackers to read sensitive documents.
View DetailsSoftware for electronic checking does not verify hostname, leading to financial loss.
View DetailsCloud-support library written in Python uses incorrect regular expression when matching hostname.
View DetailsWeb browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
View DetailsDatabase program truncates the Common Name during hostname verification, allowing spoofing.
View DetailsIncorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
View DetailsMail server's incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
View DetailsLDAP server's incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
View DetailsPayment processing module does not verify hostname when connecting to PayPal using PHP fsockopen function.
View DetailsSmartphone device does not verify hostname, allowing spoofing of mail services.
View DetailsE-commerce module does not verify hostname when connecting to payment site.
View DetailsJava library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
View DetailsWeb browser does not validate Common Name, allowing spoofing of https sites.
View DetailsCWE-297: Improper Validation of Certificate with Host Mismatch is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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. 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. If the certificate's host-specific data is not properly checked - such as the Common Name (CN) in the Subject or the Subject Alternative Name (SAN) extension of an X.509 certificate - it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host. 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. This weakness can occur even when the product uses Certificate Pinning, if the product does not verify the hostname at the time a certificate is pinned.
If exploited, CWE-297 (Improper Validation of Certificate with Host Mismatch) it can compromise Access Control, Authentication and Other, leading to outcomes such as Gain Privileges or Assume Identity and Other.
Recommended mitigations for CWE-297 include: Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed. 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.
CWE-297 can be detected using Dynamic Analysis with Manual Results Interpretation and Black Box. Combining automated tooling with manual review typically yields the best coverage.
CWE-297 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-297, including CVE-2012-5810, CVE-2012-5811, CVE-2012-5807, CVE-2012-3446 and CVE-2009-2408. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-297 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.