HostnameVerifier não seguro
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Categoria do OWASP: MASVS-CODE - Qualidade do código (link em inglês)
Visão geral
A implementação de HostnameVerifier é responsável por verificar se o
nome do host no certificado do servidor corresponde ao do servidor a que o
cliente está tentando se conectar.
Uma implementação não segura do HostnameVerifier em um app Android não
verifica corretamente o nome do host do servidor
com que o aplicativo está se comunicando. Isso permite que um invasor
se passe por um servidor legítimo e induza o aplicativo a enviar dados
sensíveis para ele.
Essa vulnerabilidade existe porque a classe HostnameVerifier tem chamadas de
função que podem pular a validação do nome do host do certificado X.509 e, em vez disso, verificar
apenas o hash do certificado. Um equívoco comum é achar que a
função SSLSession#isValid executa
uma operação relacionada à segurança, quando, na realidade, o objetivo dela é apenas
verificar se uma sessão é válida e está disponível para
ser retomada ou para participar dela. Isso
não valida a segurança de uma sessão. A
classe HostnameVerifier foi substituída por NetworkSecurityConfig.
Impacto
Implementações não seguras do HostnameVerifier podem levar a vulnerabilidades que podem
ser usadas para realizar ataques "man-in-the-middle" (MiTM) no tráfego de rede do
aplicativo vítima. O impacto dessa exploração de código não seguro é que os dados
da rede do aplicativo de um usuário podem ser comprometidos por invasores na rede (de forma remota
ou local) caso esse código seja acionado. O impacto depende do conteúdo do tráfego
de rede que está sendo exposto acidentalmente (PII, informações particulares,
valores de sessões sensíveis, credenciais de serviço etc.).
Mitigações
Use o NetworkSecurityConfig.xml para garantir que todas
as conexões de produção, teste, depuração e estágio de desenvolvimento sejam tratadas corretamente, em vez de usar ou implementar um código de validação de certificado TLS/SSL personalizado.
Recursos
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-26 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-26 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)"]]
