HostnameVerifier non sécurisé
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Catégorie OWASP : MASVS-CODE : qualité du code
Présentation
L'implémentation de HostnameVerifier est chargée de vérifier que le nom d'hôte du certificat du serveur correspond à celui du serveur auquel le client tente de se connecter.
Une implémentation HostnameVerifier non sécurisée dans une application Android est une implémentation qui ne vérifie pas correctement le nom d'hôte du serveur avec lequel l'application communique. Cela peut permettre à un pirate informatique d'usurper l'identité d'un serveur légitime et d'inciter l'application à envoyer des données sensibles au pirate.
Cette faille existe, car la classe HostnameVerifier comporte des appels de fonction pouvant ignorer la validation du nom d'hôte du certificat X.509 et vérifier uniquement le hachage du certificat. L'idée répandue que la fonction SSLSession#isValid effectue une opération liée à la sécurité est fausse. En réalité, elle sert uniquement à vérifier si une session est valide et si elle peut être reprise ou rejointe, ce qui ne valide pas sa sécurité. La classe HostnameVerifier a été remplacée par NetworkSecurityConfig.
Impact
Les implémentations HostnameVerifier non sécurisées peuvent entraîner des failles qui permettent de lancer des attaques MiTM ("man in the middle") sur le trafic réseau à partir de l'application victime. Si vous exploitez ce code non sécurisé, les données réseau de l'application d'un utilisateur peuvent être compromises par des pirates informatiques (à distance ou localement) si ce code est déclenché. L'impact dépend du contenu du trafic réseau exposé par inadvertance (informations permettant d'identifier personnellement l'utilisateur, informations privées, valeurs de session sensibles, identifiants de service, etc.).
Stratégies d'atténuation
Utilisez la fonctionnalité NetworkSecurityConfig.xml pour vous assurer que toutes les connexions de production, de test, de débogage et de développement sont correctement gérées, au lieu d'utiliser ou d'implémenter un code de validation de certificat TLS/SSL personnalisé.
Ressources
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2023/12/26 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2023/12/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)"]]
