FIXMEclient := &http.Client{
+ Transport: &http.Transport{
+ TLSClientConfig: &tls.Config{
+ InsecureSkipVerify: true, // Non-compliant
+ },
+ },
+}
+
+client.Get("https://example.com")FIXME: add a description
+This vulnerability allows attackers to impersonate a trusted host.
FIXME: remove the unused optional headers (that are commented out)
+Transport Layer Security (TLS) provides secure communication between systems +over the internet by encrypting the data sent between them. In this process, +the role of hostname validation, combined with certificate validation, is to +ensure that a system is indeed the one it claims to be, adding an extra layer +of trust and security.
+When hostname validation is disabled, the client skips this critical check. +This creates an opportunity for attackers to pose as a trusted entity and +intercept, manipulate, or steal the data being transmitted.
+To do so, an attacker would obtain a valid certificate
+authenticating example.com, serve it using a different hostname, and
+the application code would still accept it.
Establishing trust in a secure way is a non-trivial task. When you disable +hostname validation, you are removing a key mechanism designed to build this +trust in internet communication, opening your system up to a number of +potential threats.
+If a system does not validate hostnames, it cannot confirm the identity of +the other party involved in the communication. An attacker can exploit this by +creating a fake server and masquerading it as a legitimate one. For example, +they might set up a server that looks like your bank’s server, tricking your +system into thinking it is communicating with the bank. This scenario, called +identity spoofing, allows the attacker to collect any data your system sends +to them, potentially leading to significant data breaches.
+The following code contains examples of disabled hostname validation.
+Hostname validation is disabled if InsecureSkipVerify is set to true for TLSClientConfig used for the transport class.
For HTTPS, it is recommended to use high-level interfaces (like http.Get()), which perform the certificate validation instead of using http.Client directly.
FIXMEclient := &http.Client{
+ Transport: &http.Transport{
+ TLSClientConfig: &tls.Config{
+ InsecureSkipVerify: true, // Non-compliant
+ },
+ },
+}
+
+client.Get("https://example.com")Usage of high-level interfaces is recommended:
+FIXMEhttp.Get("https://example.com")To fix the vulnerability of disabled hostname validation, it is strongly +recommended to first re-enable the default validation and fix the root cause: the validity of the certificate.
+If a hostname validation failure prevents connecting to the target server, keep +in mind that one system’s code should not work around another system’s problems, +as this creates unnecessary dependencies and can lead to reliability issues.
+Therefore, the first solution is to change the remote host’s certificate to +match its identity. If the remote host is not under your control, consider replicating its +service to a server whose certificate you can change yourself.
+In case the contacted host is located on a development machine, and if there +is no other choice, try following this solution:
+Create a self-signed certificate for that machine.
+Add this self-signed certificate to the system’s trust store.
+If the hostname is not localhost, add the hostname in the /etc/hosts file.
OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
+OWASP - Mobile AppSec Verification Standard - Network Communication Requirements
+OWASP - Mobile Top 10 2016 Category M3 - Insecure Communication
+CWE - CWE-297 - Improper Validation of Certificate with Host Mismatch
+STIG Viewer - Application Security and Development: V-222550 - The application must validate certificates by constructing a certification path to an accepted trust anchor.
+(visible only on this page)
+Enable server hostname verification on this SSL/TLS connection
+(visible only on this page)
+.NET API offers a single callback to override TLS certificates chain and hostname validation. RSPEC-4830 already detects that this callback always accept the server certificate without validation. There is no easy way to detects code that validates the certificate chain and fails to validate the server hostname in this callback.
+Therefore, this will not be implemented for .NET langauges.
+