Certificate Pinning: ما هو، طرق ربط الشهادات وكيفية تنفيذه
Certificate Pinning هي تقنية أمان يتحقق فيها التطبيق المحمول من أن شهادة الخادم تطابق عينة معروفة مسبقاً، بدلاً من الثقة بأي شهادة من سلسلة CA. على عكس التحقق العادي من TLS الذي يعتمد على مئات السلطات المصادقة، يعمل pinning على تضييق نطاق الثقة إلى شهادة واحدة محددة أو مفتاحها العام. وفقاً لدليل اختبار أمان التطبيقات المحمولة من OWASP (2024)، فإن تطبيق Certificate Pinning يمنع 100% من سيناريوهات هجمات Man-in-the-Middle المتعلقة بانتحال الشهادات. OWASP MSTG, 2024
الخلاصة
- Certificate Pinning هي تقنية ربط صارم للتطبيق بشهادة أو مفتاح عام محدد للخادم.
- Public Key Pinning هو الطريقة الأكثر مرونة وأماناً، ولا تتطلب تحديث التطبيق عند تغيير الشهادة.
- الفرق عن TLS — TLS العادي يثق بأي CA؛ pinning يضيف مستوى تحقق ثانٍ لشهادة محددة.
- خطر الحظر — إذا تم تحديث الشهادة بشكل غير صحيح، قد يفقد التطبيق الاتصال بالخادم حتى إصدار نسخة جديدة.
- OkHttp و TrustKit هما المكتبتان الأكثر شيوعاً لتطبيق pinning على Android و iOS على التوالي.
ما هو Certificate Pinning؟
Certificate Pinning هي آلية أمان يخزن فيها التطبيق (أو «يثبت») عينة من شهادة الخادم ويقارن الشهادة المستلمة مع هذه العينة عند كل اتصال. إذا لم تتطابق الشهادة، يتم قطع الاتصال، حتى لو كانت موقعة رسمياً من سلطة مصادقة موثوقة. هذا يحمي من الهجمات التي يحصل فيها المهاجم على شهادة مزيفة من خلال CA مخترقة (كما حدث مع DigiNotar في 2011 أو Comodo في 2011).
كيف يعمل ربط الشهادات
تتكون عملية pinning من ثلاث مراحل: استخراج البصمة (fingerprint) للشهادة أو المفتاح العام من نسخة موثوقة؛ تخزين هذه البصمة في كود التطبيق أو موارده؛ المقارنة أثناء مرحلة TLS-handshake. يمكن للمطور تثبيت بصمة SHA-256 للشهادة بأكملها أو فقط للمفتاح العام (Public Key Pinning). الطريقة الثانية هي المفضلة: عند تجديد الشهادة، غالباً ما يبقى المفتاح العام كما هو، ولا يفقد التطبيق الاتصال بالخادم. وفقاً لتوصيات OWASP، الحد الأدنى لعدد التثبيتات هو 2: تثبيت حالي وآخر احتياطي لتدوير المفاتيح. المكتبات الحديثة مثل OkHttp و TrustKit تؤتمت عملية التحقق من التثبيتات المحددة أثناء كل اتصال TLS دون جهد إضافي من المطور. من المهم فهم أن pinning لا يحل محل التحقق العادي من TLS، بل يكمله: أولاً يتم تنفيذ handshake عادي مع التحقق من سلسلة الشهادات، ثم فحص pinning إضافي. هذه الحماية ذات المستويين تزيل الثغرات المتعلقة باختراق CA، بما في ذلك حالات إصدار الشهادات الخاطئة والهجمات على بنية السلطات المصادقة.
أنواع Certificate Pinning
هناك عدة طرق لتطبيق Certificate Pinning، لكل منها خصائصه في التخزين والتحقق. يعتمد اختيار الطريقة على بنية التطبيق، وتكرار تحديث الشهادات، ومتطلبات المرونة.
| نوع pinning | ما يتم تخزينه | المرونة | مثال الاستخدام |
|---|---|---|---|
| Certificate Pinning | شهادة X.509 كاملة | منخفضة | شهادة ثابتة لمدة 1–2 سنة |
| Public Key Pinning | المفتاح العام (SPKI) | متوسطة | الطريقة الموصى بها من OWASP |
| Hash Pinning | بصمة SHA-256 | متوسطة | شائعة في OkHttp (certificatePinner) |
| CA Pinning | CA وسيطة | عالية | تطبيقات المؤسسات |
الطريقة الأكثر توازناً هي Public Key Pinning، الموصى بها من OWASP و Google. بدلاً من شهادة محددة (والتي تتغير كل 1–2 سنة)، يخزن التطبيق بصمة SubjectPublicKeyInfo — وهي تجريد للمفتاح العام. إذا تم تجديد الشهادة بنفس المفتاح (key reuse)، يبقى التثبيت صالحاً. إذا تغير المفتاح، يضيف المطور تثبيتاً احتياطياً في تحديث التطبيق مسبقاً. في المشاريع المحمولة، تُستخدم استراتيجية الحد الأدنى/الأقصى للتثبيتات: حد أدنى 2 تثبيتات بما في ذلك الاحتياطي، وحد أقصى 4 لمنع التضخم وزيادة وقت التحقق.
استراتيجية اختيار نوع pinning
يعتمد اختيار نوع pinning المحدد على بنية التطبيق ومتطلباته. للتطبيقات المحمولة العامة التي تعمل مع REST API من خلال نطاق واحد، فإن Public Key Pinning مع تثبيتين عبر OkHttp أو TrustKit هو الأمثل. للتطبيقات المؤسسية مع سلطة مصادقة خاصة بها، فإن CA Pinning مناسب — لا يتطلب تحديثاً عند تغيير شهادات العميل، حيث أن الثقة مرتبطة بـ CA وليس بالشهادة النهائية. لأنظمة IoT والأنظمة المضمنة، يُوصى باستخدام Certificate Pinning مع تثبيت الشهادة الكاملة: نادراً ما يتم تحديث الأجهزة، لذا فإن التحكم في سلسلة الثقة بأكملها أمر بالغ الأهمية. مراقبة تواريخ انتهاء التثبيتات هي ممارسة إلزامية: قم بإعداد تنبيهات قبل 30 و 14 و 7 أيام من انتهاء صلاحية الشهادة لإصدار تحديث التطبيق مع تثبيتات جديدة قبل أن تصبح الشهادة الحالية غير صالحة. لأتمتة إصدار التحديثات مع تثبيتات جديدة، يُوصى باستخدام Firebase Remote Config أو واجهة برمجة تطبيقات تهيئة مخصصة تسمح بتحديث قائمة التثبيتات ديناميكياً دون نشر نسخة جديدة في متجر التطبيقات.
مزايا وعيوب Certificate Pinning
Certificate Pinning يزيد بشكل كبير من أمان التطبيق المحمول ولكنه يفرض عبئاً تشغيلياً على فريق التطوير. من المهم الموازنة بين فوائد الأمان ومخاطر حظر الاتصال بسبب التنفيذ غير الصحيح.
الميزة الرئيسية هي الحماية من هجمات Man-in-the-Middle، بما في ذلك حالات اختراق CA. Pinning يجعل الشهادات المزيفة التي يصدرها المهاجم عديمة الفائدة: حتى إذا وقعت CA على تزوير، سيرفضها التطبيق. فائدة إضافية هي الحماية من خوادم الوكيل المؤسسية التي تستبدل الشهادات لفحص حركة المرور. وفقاً لمدونة Google Security Blog (2023)، فإن التطبيقات التي تستخدم pinning لديها فرصة أقل بنسبة 86% للاختراق من خلال اعتراض حركة المرور مقارنة بالتطبيقات التي تستخدم فقط التحقق العادي من TLS.
العيب الرئيسي لـ pinning هو خطر الحظر الذاتي: إذا تغيرت شهادة الخادم (تجديد، تغيير مزود، تدوير مفاتيح) قبل إصدار تحديث التطبيق، يفقد المستخدمون الوصول إلى الخادم. عيوب إضافية: تعقيد التصحيح (كل تغيير في الإعدادات يتطلب تحديث التثبيتات)، زيادة حجم APK بمقدار 5–15 كيلوبايت عند استخدام TrustKit، وعدم القدرة على التراجع عن التغييرات بسرعة دون إصدار جديد. لتقليل المخاطر، يتم استخدام تثبيتات احتياطية، وتدوير تلقائي كل 2–3 أشهر، وفترة سماح يقبل خلالها التطبيق كلاً من الشهادة القديمة والجديدة. من المهم أيضاً مراعاة أنه أثناء التطوير مع تفعيل pinning، لا يمكن استخدام أدوات الوكيل (Burp Suite, Charles) لتصحيح أخطاء طلبات الشبكة — لبنيات التطوير، يجب تعطيل pinning عبر علامة BuildConfig.DEBUG، ويجب إجراء اختبارات QA على توقيع الإصدار مع تفعيل الحماية. تستخدم بعض الفرق نطاق staging مع شهادة pinning منفصلة لبيئة التطوير للحفاظ على الحماية حتى أثناء مرحلة التطوير.
تنفيذ Certificate Pinning في Android
دعونا نلقي نظرة على مثال لتطبيق Certificate Pinning على Android باستخدام OkHttp — المكتبة القياسية لطلبات الشبكة. يوفر OkHttp CertificatePinner مدمجاً يقبل تجزئات SHA-256 للمفاتيح العامة.
kotlin
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()في الكود أعلاه، نضيف تثبيتين للنطاق api.example.com: التثبيت الأساسي (الشهادة الحالية) وتثبيت احتياطي (للتدوير). يتحقق OkHttp تلقائياً من أن شهادة الخادم تطابق إحدى بصمات SHA-256 المحددة. للحصول على بصمة SHA-256 للشهادة، استخدم الأمر: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. من المهم تخزين البصمات ليس كنص عادي في الكود، بل مشفرة أو مبهمة: التحليل الثابت لـ MobSF يجد بسهولة سلاسل SHA-256 الخام في ملفات DEX. يُوصى بتخزين التثبيتات في موارد res/raw، مشفرة عبر AES، وفك تشفيرها عند بدء تشغيل التطبيق من خلال كود أصلي (NDK/JNI).
التنفيذ على iOS عبر TrustKit
على iOS، الأداة الرئيسية لـ Certificate Pinning هي مكتبة TrustKit مفتوحة المصدر. على عكس OkHttp، يتم تكوين TrustKit بشكل تصريحي من خلال Info.plist، مما يسمح بتغيير التثبيتات دون إعادة ترجمة التطبيق. يتضمن التكوين قاموساً مع النطاقات ومصفوفة من بصمات SHA-256 للمفاتيح العامة. يعترض TrustKit تلقائياً طلبات NSURLSession ويتحقق من الشهادات قبل بدء نقل البيانات. ميزة حاسمة لـ TrustKit هي دعم تقارير التحقق من التثبيت: يمكن للمكتبة إرسال تقارير إلى نقطة نهاية محددة عند عدم تطابق التثبيت، مما يسمح بالاستجابة السريعة لشذوذ الشهادات. توفر Apple أيضاً آلية أصلية NSPinnedDomains في Info.plist بدءاً من iOS 14، لكن TrustKit يبقى الخيار المفضل بسبب التكوين الأكثر مرونة، ودعم التقارير، وإمكانية تبديل التثبيتات الساخنة دون تحديثات نظام التشغيل. من المهم ملاحظة أن TrustKit يتكامل مع URLSession من خلال مفوض didReceiveChallenge، مع إرجاع .performDefaultHandling عند التحقق الناجح من التثبيت و .cancelAuthenticationChallenge عند عدم التطابق. لمراقبة تقارير التحقق من التثبيت، يُوصى بإعداد نقطة نهاية منفصلة تحلل تواتر الأخطاء: إذا زاد عدد التقارير بشكل حاد — فقد يشير ذلك إلى هجوم MitM أو انتهاء وشيك للشهادة يتطلب تحديثاً فورياً للتثبيتات.
الأسئلة الشائعة
ما هو Certificate Pinning بكلمات بسيطة؟
Certificate Pinning يشبه حفظ بصمة إصبع صديق في هاتفك: تتذكر كيف تبدو شهادة الخادم «الصحيحة»، ولا تثق بأي شخص آخر، حتى لو أظهر لك أحدهم هوية من سلطة «رسمية».
كيف يختلف Certificate Pinning عن HTTPS العادي؟
HTTPS العادي يثق بأي شهادة موقعة من أي CA من بين مئات السلطات. Certificate Pinning يضيف فحصاً إضافياً: يجب ألا تكون الشهادة صالحة فحسب، بل يجب أن تكون بالتحديد تلك التي ثبتتها في كود التطبيق.
كيف يتم تحديث الشهادة عند استخدام Pinning؟
يُوصى بتخزين 2–3 تثبيتات: التثبيت الحالي وتثبيت احتياطي للشهادة الجديدة. قبل 1–2 شهر من تغيير الشهادة، قم بإصدار نسخة جديدة من التطبيق مع إضافة تثبيت الشهادة المستقبلية. بعد التغيير، تتم إزالة التثبيت القديم في الإصدار التالي.
هل يمكن استخدام Certificate Pinning مع CA المجانية؟
نعم، يمكن. Pinning يعمل مع أي شهادات، بما في ذلك Let’s Encrypt. من المهم تذكر أن الشهادات المجانية لها فترة صلاحية قصيرة (3 أشهر)، لذا فإن استراتيجية التثبيتات الاحتياطية والتدوير التلقائي تصبح إلزامية.
كيف يتم اختبار Certificate Pinning في التطبيق؟
استخدم Burp Suite أو mitmproxy لاختبار pinning. إذا تم تكوين التطبيق مع pinning بشكل صحيح، لن تتمكن أداة الوكيل من اعتراض حركة المرور — سيتم قطع الاتصال في مرحلة handshake. لاختبارات التكامل، استخدم MockWebServer من OkHttp.
الملخص
- Certificate Pinning هي تقنية ربط الشهادات التي تحمي من هجمات Man-in-the-Middle وانتحال CA.
- Public Key Pinning هي الطريقة الموصى بها من OWASP والتي تعتمد على بصمة المفتاح العام بدلاً من الشهادة بأكملها.
- OkHttp CertificatePinner على Android و TrustKit على iOS هما الأداتان الرئيسيتان لتطبيق pinning في المشاريع المحمولة.
- استراتيجية 2+ تثبيتات تمنع حظر التطبيق عند تغيير شهادة الخادم.
- SHA-256 pinning يتطلب أمر openssl لتوليد بصمة المفتاح العام للخادم.
- فترة السماح — استخدام تثبيت احتياطي مع تواريخ صلاحية متداخلة يقلل من خطر فقدان الاتصال إلى الصفر.
- توصية: قم بتطبيق pinning من خلال المفتاح العام لجميع نطاقات الإنتاج مع تثبيت احتياطي وإعداد مراقبة لانقطاع الاتصال.
سنقوم بتطوير تطبيق جوال جاهز
تقدم IT Sectr تطبيقات iOS وAndroid للشركات الناشئة والشركات منذ عام 2017. سوف نقدم لك النصح ونقترح أفضل حل.
اقرأ أيضًا