Improper Validation of Certificate with Host Mismatch
This vulnerability occurs when an application accepts a valid SSL/TLS certificate without properly verifying that it actually belongs to the specific host it's connecting to. Even a correctly signed certificate from a trusted authority can be misused if the hostname check is missing or flawed.
When your application connects to a server, it must verify that the certificate presented matches the intended hostname. This is done by checking the Common Name (CN) or, more reliably, the Subject Alternative Name (SAN) fields in the certificate. If this validation is skipped or implemented incorrectly, an attacker with a valid certificate for a different domain can impersonate your trusted service, leading to man-in-the-middle attacks and data interception. Common validation pitfalls include incomplete string comparisons that can be tricked by special characters, or failing to perform hostname checks when using certificate pinning. Always validate the hostname at the time of pinning and use established library functions for hostname verification instead of custom string matching, as these functions correctly handle edge cases like null bytes and wildcards.
Impact: Gain Privileges or Assume Identity
The data read from the system vouched for by the certificate may not be from the expected system.
Impact: Other
Trust afforded to the system in question - based on the malicious certificate - may allow for spoofing or redirection attacks.
ID : DX-122
The following OpenSSL code obtains a certificate and verifies it.Code Example:
c// do secret things* }
High
- CLASP