واجهة HostnameVerifier غير آمنة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
فئة OWASP: MASVS-CODE: جودة الرموز البرمجية
نظرة عامة
تتحمّل عملية تنفيذ HostnameVerifier مسؤولية التحقّق من تطابق اسم المضيف في شهادة الخادم مع اسم المضيف للخادم الذي يحاول العميل الاتصال به.
التنفيذ غير الآمن لواجهة HostnameVerifier في تطبيق Android هو
تنفيذ لا يتحقق بشكل صحيح من اسم المضيف للخادم الذي
يتواصل معه التطبيق. ويمكن أن يسمح ذلك للمهاجم بالتنكر بصفته خادمًا شرعيًا وخداع التطبيق لإرسال بيانات حساسة إليه.
تحدث هذه الثغرة الأمنية لأنّ فئة HostnameVerifier تحتوي على طلبات اتّباع دالة
يمكنها تخطّي عملية التحقّق من اسم المضيف لشهادة X.509، وبدلاً من ذلك، تحقّق فقط من تجزئة الشهادة. من المفاهيم الخاطئة الشائعة أنّ الدالة
SSLSession#isValid تُجري عملية ذات صلة بالأمان، بينما
الغرض منها في الواقع هو التحقّق فقط مما إذا كانت الجلسة صالحة ومتاحة
لاستئنافها أو الانضمام إليها، ولا يتحقق أي منهما من أمان الجلسة. تم استبدال فئة
HostnameVerifier بفئة NetworkSecurityConfig.
التأثير
يمكن أن تؤدي عمليات التنفيذ غير الآمنة لواجهة HostnameVerifier إلى ثغرات أمنية يمكن استخدامها لشن هجمات وسيطة على حركة بيانات الشبكة من التطبيق المستهدف. ويؤدي استغلال هذا الرمز غير الآمن إلى إمكانية اختراق بيانات شبكة
التطبيق الخاصة بالمستخدم من قِبل مخترِقي الشبكة (عن بُعد أو
على الجهاز) في حال تنشيط هذا الرمز. يعتمد التأثير على محتوى
زيارات الشبكة التي يتم الكشف عنها عن غير قصد (معلومات تحديد الهوية الشخصية والمعلومات الخاصة
وقيم الجلسات الحسّاسة ومعلومات اعتماد الخدمة وما إلى ذلك).
إجراءات التخفيف
استخدِم NetworkSecurityConfig.xml لضمان معالجة جميع
عمليات الاتصال في مرحلة الإنتاج والاختبار وتصحيح الأخطاء ومرحلة التطوير بشكلٍ سليم، بدلاً من استخدام رمز التحقّق المخصّص لشهادة بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) أو تنفيذه.
المراجع
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)"]]
