CWE-322 describes a product that performs a key exchange with another party without verifying who that party is. The channel ends up encrypted, but possibly to the wrong person.
Clients are the usual victims: apps, devices and services that connect out to a server and trust whatever answers.
How it happens
A key exchange keeps the data between two endpoints intact and private from outsiders. It does not prove the endpoints are who they claim to be. MITRE explains that an attacker can impersonate one side by modifying traffic. Typically a victim client contacts a malicious server posing as a trusted one. If the client skips authentication, or ignores an authentication failure, the fake server can proceed as if it were the real one and may then request sensitive information.
Common causes are disabled certificate checks used during testing that reach production, and code that catches a verification error and carries on.
# Vulnerable: certificate verification turned off
requests.get("https://api.example.com/data", verify=False)
What an attacker gains
MITRE lists two effects. Authentication is bypassed, so an assumed protection of encryption does not hold. And confidentiality suffers, because encrypted communication between a user and a trusted host can be sniffed by an actor in the middle who holds the keys.
How to find it
Static analysis can flag some instances, such as disabled verification flags. Also test directly: point the client at a server with an untrusted certificate and see whether it connects.
How to fix it
- Include proper authentication in the design from the start.
- Implement every check needed to confirm the identity of each party, including certificate chain and host name validation.
- Treat an authentication failure as fatal. Never log it and continue.
Quick check
Is encryption alone enough to stop an impersonator?
No. Encryption protects data in transit between two endpoints. Without authentication, one of those endpoints can be the attacker.
