הטמעת הצמדת אישורים (Certificate Pinning) לאפליקציות מובייל

הטמעת Certificate Pinning לאפליקציות מובייל

אפליקציות מיורטות באמצעות Charles Proxy או Frida — קריאת בקשות, שינוי תגובות, חקירת ה-API. זה קורה מכיוון שחיבורי TLS מאמתים אישורים מול רשויות אישורים (CA) של המערכת, והמשתמש (או הבודק) פשוט הוסיף את ה-CA שלו כרשות מהימנה. במהלך 5 השנים האחרונות, הטמענו Certificate Pinning ביותר מ-30 פרויקטים למובייל — מסטארטאפים פינטק ועד פתרונות ארגוניים. זה סוגר לחלוטין את וקטור התקיפה MITM במכשירים שאינם מושרשים. אנו מגדירים Pinning ב-iOS וב-Android, כולל מפתחות גיבוי ובדיקות CI. לוחות הזמנים נעים בין 2 ל-5 ימים, תלוי במספר השרתים. רוצים להעריך את הפרויקט שלכם? פשוט צרו קשר.

למה Public Key Pinning עדיף על Certificate Pinning

Certificate Pinning — הלקוח מאחסן את האישור המלא (או את ה-hash מסוג SHA-256 שלו) ומשווה אותו למה שהשרת שולח. האישור משתנה בכל חידוש — כל 1-2 שנים. אם תשכחו לעדכן את ה-pin לפני הרוטציה, האפליקציה תפסיק לעבוד עבור כל המשתמשים בו-זמנית.

Public Key Pinning (בסגנון HPKP) — מצמיד את ה-hash של SubjectPublicKeyInfo. כאשר האישור מתחדש, המפתח הפרטי נשאר לעיתים קרובות זהה, כך שה-pin נשאר תקף. זו הבחירה הנכונה לסביבת ייצור. בנוסף, שמרו על pin גיבוי — hash של מפתח גיבוי (יכול להיות מה-CA שלכם). הבה נשווה בין הגישות:

כיצד אנו מיישמים Pinning: תהליך שלב-אחר-שלב

iOS: NSURLSession + TrustKit

func urlSession( _ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void ) {
    guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust, let serverTrust = challenge.protectionSpace.serverTrust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    guard let serverCert = SecTrustGetCertificateAtIndex(serverTrust, 0), let serverKey = SecCertificateCopyKey(serverCert) else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    let serverKeyData = SecKeyCopyExternalRepresentation(serverKey, nil)! as Data
    let serverKeyHash = sha256(data: serverKeyData)
    let pinnedHashes = ["base64encodedSHA256ofSubjectPublicKeyInfo=="]
    if pinnedHashes.contains(serverKeyHash) {
        completionHandler(.useCredential, URLCredential(trust: serverTrust))
    } else {
        completionHandler(.cancelAuthenticationChallenge, nil)
    }
}

לפרויקטים עם מספר שרתים, השתמשו ב-TrustKit — מוגדר דרך Info.plist, תומך ב-pins גיבוי ודיווח הפרות.

Android: OkHttp CertificatePinner

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com", "sha256/AAAAAAAAA...primaryKeyHash==")
    .add("api.example.com", "sha256/BBBBBBBBB...backupKeyHash==")
    .build()
val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

OkHttp מחשב אוטומטית את ה-SHA-256 של SubjectPublicKeyInfo. במקרה של אי-התאמה — func urlSession( _ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void ) { guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust, let serverTrust = challenge.protectionSpace.serverTrust else { completionHandler(.cancelAuthenticationChallenge, nil) return } guard let serverCert = SecTrustGetCertificateAtIndex(serverTrust, 0), let serverKey = SecCertificateCopyKey(serverCert) else { completionHandler(.cancelAuthenticationChallenge, nil) return } let serverKeyData = SecKeyCopyExternalRepresentation(serverKey, nil)! as Data let serverKeyHash = sha256(data: serverKeyData) let pinnedHashes = ["base64encodedSHA256ofSubjectPublicKeyInfo=="] if pinnedHashes.contains(serverKeyHash) { completionHandler(.useCredential, URLCredential(trust: serverTrust)) } else { completionHandler(.cancelAuthenticationChallenge, nil) } } . קבלו hashes דרך openssl:

openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
 | openssl x509 -pubkey -noout \
 | openssl pkey -pubin -outform der \
 | openssl dgst -sha256 -binary \
 | openssl enc -base64

עבור Flutter, השתמשו בחבילת val certificatePinner = CertificatePinner.Builder() .add("api.example.com", "sha256/AAAAAAAAA...primaryKeyHash==") .add("api.example.com", "sha256/BBBBBBBBB...backupKeyHash==") .build() val client = OkHttpClient.Builder() .certificatePinner(certificatePinner) .build() או ב-wrapper native דרך ערוצי פלטפורמה.

מהם הסיכונים בהטמעה לא נכונה?

הכאב התפעולי העיקרי — רוטציית מפתחות. 30+ ימים לפני חידוש האישור, פרסמו עדכון עם pin גיבוי חדש, תנו למשתמשים לעדכן, ואז סובבו את המפתח. אם זה לא נעשה, האפליקציה מאבדת קישוריות לשרת עבור כל הלקוחות. במבני debug, pinning מושבת בדרך כלל באמצעות דגל SSLPeerUnverifiedException או flavor נפרד. ודאו שבניית release ב-CI נבנית עם pinning — אחרת אתם מאבדים הגנה.

מה כלול בעבודה שלנו

• הגדרת Pinning עבור כל שרתי האפליקציה (iOS + Android, עד 5 שרתים כלולים).
• Pin גיבוי — הוספת hash של מפתח גיבוי לרוטציה חלקה.
• אינטגרציית CI — הגדרת דגלים להפרדת מבני debug/release.
• תיעוד — תיאור נוהל עדכון ה-pin ואנשי קשר לשחרור חירום.
• תמיכה — למשך 30 יום לאחר ההטמעה, אנו עונים על שאלות ועוזרים ברוטציה הראשונה.

לוחות זמנים

הגדרת Pinning לשרת אחד עם pins גיבוי — 2-3 ימים. לפרויקטים עם 3+ שרתים — עד 5 ימים. התמחור מחושב באופן אישי, בהתאם למורכבות ולמספר הפלטפורמות.

קבלו ייעוץ: צרו קשר, ואנחנו נעריך את לוחות הזמנים לפרויקט שלכם. כתבו לנו — נעריך את הפרויקט שלכם תוך יום אחד.