Certificate Pinning (sertifikat bağlama) — bu, mobil proqramın server sertifikatının əvvəlcədən məlum olan nümunə ilə uyğun olub-olmadığını yoxladığı, sadəcə CA zəncirindəki hər hansı sertifikata etibar etmədiyi təhlükəsizlik texnikasıdır. Yüzlərlə sertifikasiya mərkəzinə əsaslanan adi TLS yoxlamasından fərqli olaraq, pinning etibarı bir konkret sertifikata və ya onun açıq açarına qədər daraldır. OWASP Mobile Security Testing Guide (2024) məlumatına görə, Certificate Pinning tətbiqi sertifikatın dəyişdirilməsi ilə bağlı Man-in-the-Middle hücumlarının 100% hallarını qapadır. OWASP MSTG, 2024
Əsas məqamlar
Certificate Pinning — proqramın server sertifikatının nümunəsini saxladığı (və ya "tikdiyi" — pin) və hər bağlantıda alınan sertifikatı bu nümunə ilə müqayisə etdiyi təhlükəsizlik mexanizmidir. Sertifikat uyğun gəlmirsə — hətta rəsmi olaraq etibarlı sertifikat mərkəzi tərəfindən imzalanmış olsa belə — bağlantı kəsilir. Bu, hücumçunun kompromitə olunmuş CA vasitəsilə saxta sertifikat əldə etdiyi hücumlardan qoruyur (DigiNotar 2011 və Comodo 2011-də olduğu kimi).
Pinning prosesi üç mərhələdən ibarətdir: etibarlı nümunədən sertifikatın və ya açıq açarın izini (fingerprint) çıxarmaq; bu izi proqramın kodunda və ya resurslarında saxlamaq; TLS-handshake mərhələsində müqayisə etmək. Tərtibatçı bütün sertifikatın SHA-256 izini və ya yalnız açıq açarın izini (Public Key Pinning) təsbit edə bilər. İkinci yanaşma daha üstündür: sertifikat uzadıldıqda açıq açar çox vaxt eyni qalır və proqram serverlə əlaqəni itirmir. OWASP tövsiyəsinə görə minimum pin sayı — 2: biri cari, biri ehtiyat (açarların rotasiyası halı üçün). OkHttp və TrustKit kimi müasir kitabxanalar əlavə tərtibatçı xərci olmadan hər TLS bağlantısında göstərilən pinlərin yoxlanılması prosesini avtomatlaşdırır. Pinning-in standart TLS yoxlamasını əvəz etmədiyini, əksinə tamamladığını başa düşmək vacibdir: əvvəlcə adi handshake sertifikat zəncirinin validasiyası ilə yerinə yetirilir, sonra isə əlavə pinning yoxlaması aparılır. Belə iki səviyyəli qoruma CA-nın kompromitə olunması, o cümlədən səhv sertifikat verilməsi halları və sertifikat mərkəzləri infrastrukturuna hücumlar ilə bağlı zəiflikləri aradan qaldırır.
Certificate Pinning tətbiqinə bir neçə yanaşma mövcuddur, hər biri öz saxlama və yoxlama xüsusiyyətlərinə malikdir. Metod seçimi proqramın arxitekturasından, sertifikat yeniləmə tezliyindən və çeviklik tələblərindən asılıdır.
| Pinning növü | Nə saxlanılır | Çeviklik | İstifadə nümunəsi |
|---|---|---|---|
| Certificate Pinning | Bütün X.509 sertifikatı | Aşağı | 1–2 il müddətinə sabit sertifikat |
| Public Key Pinning | Açıq açar (SPKI) | Orta | OWASP tərəfindən tövsiyə olunan yanaşma |
| Hash Pinning | SHA-256 izi | Orta | OkHttp-də məşhurdur (certificatePinner) |
| CA Pinning | Aralıq CA | Yüksək | Korporativ proqramlar |
Ən balanslı metod Public Key Pinning hesab olunur, OWASP və Google tərəfindən tövsiyə edilir. Konkret sertifikat (hər 1–2 ildən bir dəyişən) əvəzinə proqram SubjectPublicKeyInfo izini — açıq açarın abstraksiyasını saxlayır. Sertifikat eyni açarla uzadılırsa (key reuse), pin etibarlı qalır. Açar dəyişirsə — tərtibatçı proqram yeniləməsində əvvəlcədən ehtiyat pin əlavə edir. Mobil layihələrdə min/max pins strategiyası tətbiq olunur: minimum 2 pin (o cümlədən ehtiyat) və maksimum 4 pin, şişkinliyin və yoxlama vaxtının artmasının qarşısını almaq üçün.
Konkret pinning növünün seçimi proqramın arxitekturası və tələblərindən asılıdır. Bir domen vasitəsilə REST API ilə işləyən ictimai mobil proqramlar üçün OkHttp və ya TrustKit vasitəsilə iki pinli Public Key Pinning optimaldır. Öz sertifikat mərkəzi olan korporativ proqramlar üçün CA Pinning uyğundur — müştəri sertifikatları dəyişdikdə yeniləmə tələb etmir, çünki etibar son sertifikata deyil, CA-ya bağlıdır. IoT və embedded sistemlər üçün tam sertifikatın təsbiti ilə Certificate Pinning tövsiyə olunur: cihazlar nadir hallarda yenilənir, buna görə də bütün etibar zəncirinə nəzarət kritikdir. Pinlərin istifadə müddətlərinin monitorinqi — məcburi təcrübədir: sertifikatın müddəti bitməmişdən 30, 14 və 7 gün əvvəl xəbərdarlıqlar qurun ki, cari sertifikat etibarsız olana qədər yeni pinlərlə proqram yeniləməsini buraxmağa vaxt olsun. Yeni pinlərlə yeniləmələrin buraxılmasını avtomatlaşdırmaq üçün Firebase Remote Config və ya proqram mağazasında yeni versiya dərc etmədən pin siyahısını dinamik yeniləməyə imkan verən öz konfiqurasiya API-nizdən istifadə etmək tövsiyə olunur.
Certificate Pinning mobil proqramın təhlükəsizliyini əhəmiyyətli dərəcədə artırır, lakin tərtibat komandasına operativ yük qoyur. Qoruma üstünlükləri ilə səhv tətbiq zamanı bağlantının bloklanması riskini tarazlaşdırmaq vacibdir.
Əsas üstünlük — CA-nın kompromitə olunması halları da daxil olmaqla Man-in-the-Middle hücumlarından qorunmadır. Pinning hücumçu tərəfindən buraxılmış saxta sertifikatları yararsız edir: hətta CA saxtanı imzalasa belə, proqram onu rədd edir. Əlavə üstünlük — trafikə nəzarət üçün sertifikatları dəyişdirən korporativ proxy serverlərdən qorunmadır. Google Security Blog (2023) məlumatına görə, pinning-li proqramlar yalnız standart TLS yoxlamasından istifadə edən proqramlarla müqayisədə trafikin ələ keçirilməsi yolu ilə sındırılma şansı 86% azdır.
Pinning-in əsas çatışmazlığı — özünü bloklama riskidir: proqram yeniləməsi buraxılana qədər server sertifikatı dəyişərsə (uzadılma, provayder dəyişikliyi, açarların rotasiyası), istifadəçilər serverə girişi itirir. Əlavə mənfi cəhətlər: sazlama çətinliyi (hər parametr dəyişikliyində pinləri yeniləmək lazımdır), TrustKit istifadə edərkən APK ölçüsünün 5–15 KB artması və yeni versiya olmadan dəyişiklikləri tez geri qaytarmaq mümkünsüzlüyü. Riskləri minimuma endirmək üçün ehtiyat pinlər, 2–3 aydan bir avtomatik rotasiya və proqramın həm köhnə, həm də yeni sertifikatı qəbul etdiyi güzəşt dövrü (grace period) tətbiq edilir. Proqramlaşdırma zamanı pinning aktiv olduqda şəbəkə sorğularının sazlanması üçün proxy alətlərindən (Burp Suite, Charles) istifadə etmək mümkün olmadığını da nəzərə almaq lazımdır — tərtibat qurğuları üçün pinning BuildConfig.DEBUG bayrağı ilə söndürülməli, QA testləri isə qoruma aktiv olan buraxılış imzası ilə aparılmalıdır. Bəzi komandalar tərtibat mərhələsində belə qorumanı qorumaq üçün ayrıca pinning sertifikatı olan staging domenindən istifadə edir.
Certificate Pinning-in Android-də OkHttp — şəbəkə sorğuları üçün standart kitabxana istifadə edərək tətbiq nümunəsinə baxaq. OkHttp açıq açarların SHA-256 heşlərini qəbul edən daxili CertificatePinner təmin edir.
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()
Yuxarıdakı kodda api.example.com domeni üçün iki pin əlavə edirik: əsas (cari sertifikat) və ehtiyat (rotasiya halı üçün). OkHttp avtomatik olaraq server sertifikatının göstərilən SHA-256 izlərindən biri ilə uyğun olub-olmadığını yoxlayır. Sertifikatın SHA-256 izini əldə etmək üçün buyruq istifadə olunur: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. İzləri kodda açıq şəkildə deyil, şifrələnmiş və ya gizlədilmiş formada saxlamaq vacibdir: MobSF statik təhlili DEX fayllarında çılpaq SHA-256 sətirlərini asanlıqla tapır. Pinləri AES vasitəsilə şifrələnmiş res/raw resurslarında saxlamaq və proqram başlanğıcında yerli kod (NDK/JNI) vasitəsilə deşifrə etmək tövsiyə olunur.
iOS-da Certificate Pinning üçün əsas alət açıq mənbəli TrustKit kitabxanasıdır. OkHttp-dən fərqli olaraq, TrustKit Info.plist vasitəsilə deklarativ şəkildə konfiqurasiya olunur, bu da proqramı yenidən kompilyasiya etmədən pinləri dəyişməyə imkan verir. Konfiqurasiya domenlər lüğəti və açıq açarların SHA-256 izləri massivini ehtiva edir. TrustKit avtomatik olaraq NSURLSession sorğularını ələ keçirir və məlumat ötürülməsinə başlamazdan əvvəl sertifikatları yoxlayır. TrustKit-in əsas xüsusiyyəti pin yoxlama hesabatları dəstəyidir: kitabxana pin uyğunsuzluğu olduqda göstərilən endpoint-ə hesabat göndərə bilər ki, bu da sertifikat anomaliyalarına operativ reaksiya verməyə imkan verir. Apple həmçinin iOS 14-dən etibarən Info.plist-də yerli NSPinnedDomains mexanizmini təmin edir, lakin TrustKit daha çevik konfiqurasiya, hesabat dəstəyi və sistem yeniləməsi olmadan pinlərin isti dəyişdirilməsi imkanı səbəbindən üstünlük verilən seçim olaraq qalır. TrustKit URLSession ilə didReceiveChallenge deleqatı vasitəsilə inteqrasiya olunur, pin yoxlaması uğurlu olduqda .performDefaultHandling, uyğunsuzluq olduqda isə .cancelAuthenticationChallenge qaytarır. Pin yoxlama hesabatlarının monitorinqi üçün səhvlərin tezliyini təhlil edən ayrıca endpoint qurmaq tövsiyə olunur: hesabatların sayı kəskin artarsa — bu, MitM hücumunu və ya dərhal pin yeniləməsi tələb edən sertifikatın yaxınlaşan müddətinin bitməsini göstərə bilər.
Tez-tez verilən suallar
Certificate Pinning — bu, telefondakı dostun barmaq izini saxlamaq kimidir: serverin "düzgün" sertifikatının necə göründüyünü xatırlayırsınız və kimsə "rəsmi" mərkəzdən vəsiqə təqdim etsə belə, artıq heç kimə etibar etmirsiniz.
Adi HTTPS yüzlərlə mərkəzdən istənilən CA tərəfindən imzalanmış istənilən sertifikata etibar edir. Certificate Pinning "yuxarıdan" yoxlama əlavə edir: sertifikat sadəcə etibarlı deyil, proqram kodunda təsbit etdiyiniz konkret sertifikat olmalıdır.
2–3 pin saxlamaq tövsiyə olunur: cari və yeni sertifikat üçün ehtiyat pin. Sertifikat dəyişikliyindən 1–2 ay əvvəl gələcək sertifikatın pini əlavə edilmiş yeni proqram versiyasını buraxın. Dəyişiklikdən sonra köhnə pin növbəti buraxılışdan silinir.
Bəli, olar. Pinning Let's Encrypt də daxil olmaqla istənilən sertifikatlarla işləyir. Pulsuz sertifikatların qısa müddətə (3 ay) malik olduğunu xatırlamaq vacibdir, buna görə də ehtiyat pinlər strategiyası və avtomatik rotasiya məcburi olur.
Pinning-i test etmək üçün Burp Suite və ya mitmproxy istifadə edin. Pinning düzgün konfiqurasiya olunmuşdursa, proxy aləti trafikə nəzarət edə bilməyəcək — bağlantı handshake mərhələsində kəsiləcək. İnteqrasiya testləri üçün OkHttp-dən MockWebServer istifadə edin.
Nəticə
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun