When establishing a secure connection the application does not check the authenticity of the domain. This can lead to a loss of data confidentiality.

Within the establishing of a protected connection (handshake) server sends its public key and certificate, which are a cryptographic proof that the public key belongs to the owner of the server, to the client. The authenticity of certificates is provided by Certification Authority.

The correspondence between the certificate and the public key transferred to the client within the handshake does not guarantee the security of the connection. The client must make sure that the public key and the certificate come from the domain to which the connection is requested. Such check is not provided at the level of SSL / TLS protocol . In its absence at the application level, the attacker can violate the connection confidentiality by redirecting the user traffic through the attacker’s server and presenting a certificate that is valid for the attacker’s domain.

A possible attack scenario:

The attacker enters the user’s WLAN and redirects user’s traffic through the attacker’s server (for example, via a DNS cache poisoning attack).
The user initiates a connection to https://safeserver.example.com.via an SSL / TLS protocol.
Instead of the https://safeserver.example.com.public key an attacker sends the application his/her own public key and a valid certificate issued by the certification authority for the https://hackedserver.example.com.domain.
The app makes sure that the resulting certificate is valid (for https://hackedserver.example.com., ignoring the fact that the certificate has been issued not for the resulting domain for which the connection was originally requested.

Perl : Hardcoded password

DerScanner Severity Score

Do you want to fix Perl : Hardcoded password in your application?

See also