Unsafe HostnameVerifier
Stay organized with collections
Save and categorize content based on your preferences.
OWASP category: MASVS-CODE: Code Quality
Overview
The HostnameVerifier
implementation is responsible for verifying that the
hostname in the server's certificate matches the hostname of the server that the
client is trying to connect to.
An unsafe HostnameVerifier implementation in an Android application is an
implementation that does not properly verify the hostname of the server with
which the application is communicating. This can allow an attacker to
impersonate a legitimate server and trick the application into sending sensitive
data to the attacker.
This vulnerability exists because the HostnameVerifier
class has function
calls that can skip X.509 certificate hostname validation and, instead, only
verify the hash of the certificate. A common misconception is that the
SSLSession#isValid
function performs a security-related operation, when
in reality its purpose is only to check if a session is valid and available for
resuming or joining; neither of which validate the security of a session. The
HostnameVerifier class has been superseded by NetworkSecurityConfig.
Impact
Unsafe HostnameVerifier implementations can lead to vulnerabilities which can be
used to perform MiTM (Man-in-The-Middle) attacks on network traffic from the
victim application. The impact of exploiting this insecure code is that a user's
application network data can be compromised by network attackers (remotely or
locally) if this code is triggered. The impact is dependent on the content of
the network traffic being inadvertently exposed (PII, private information,
sensitive session values, service credentials, etc).
Mitigations
Use the NetworkSecurityConfig.xml to ensure that all
production, testing, debugging, and dev stage connections are properly handled
rather than using or implementing custom TLS/SSL certificate validation code.
Resources
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2024-11-20 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-11-20 UTC."],[],[],null,["# Unsafe HostnameVerifier\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nThe [`HostnameVerifier`](/reference/javax/net/ssl/HostnameVerifier#verify(java.lang.String,%20javax.net.ssl.SSLSession)) implementation is responsible for verifying that the\nhostname in the server's certificate matches the hostname of the server that the\nclient is trying to connect to.\n\nAn unsafe HostnameVerifier implementation in an Android application is an\nimplementation that does not properly verify the hostname of the server with\nwhich the application is communicating. This can allow an attacker to\nimpersonate a legitimate server and trick the application into sending sensitive\ndata to the attacker.\n\nThis vulnerability exists because the `HostnameVerifier` class has function\ncalls that can skip X.509 certificate hostname validation and, instead, only\nverify the hash of the certificate. A common misconception is that the\n[`SSLSession#isValid`](/reference/javax/net/ssl/SSLSession#isValid()) function performs a security-related operation, when\nin reality its purpose is only to check if a session is valid and available for\nresuming or joining; neither of which validate the *security* of a session. The\nHostnameVerifier class has been superseded by [NetworkSecurityConfig](/training/articles/security-config).\n\nImpact\n------\n\nUnsafe HostnameVerifier implementations can lead to vulnerabilities which can be\nused to perform MiTM (Man-in-The-Middle) attacks on network traffic from the\nvictim application. The impact of exploiting this insecure code is that a user's\napplication network data can be compromised by network attackers (remotely or\nlocally) if this code is triggered. The impact is dependent on the content of\nthe network traffic being inadvertently exposed (PII, private information,\nsensitive session values, service credentials, etc).\n\nMitigations\n-----------\n\nUse the [NetworkSecurityConfig.xml](/training/articles/security-config) to ensure that all\nproduction, testing, debugging, and dev stage connections are properly handled\nrather than using or implementing custom TLS/SSL certificate validation code.\n\nResources\n---------\n\n- [Network Security Configuration Documentation](/training/articles/security-config)\n- [This check looks for implementations of HostnameVerifier whose verify method always returns true (thus trusting any hostname)](https://googlesamples.github.io/android-custom-lint-rules/checks/BadHostnameVerifier.md.html)\n- [Developer documentation for the HostnameVerifier class](/reference/javax/net/ssl/HostnameVerifier#verify(java.lang.String,%20javax.net.ssl.SSLSession))\n- [AllowAllHostnameVerifierDetector class in Android](https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:lint/libs/lint-checks/src/main/java/com/android/tools/lint/checks/AllowAllHostnameVerifierDetector.java)"]]