אבטחת אפליקציות מובייל: OWASP MASVS, Pinning והגנה מפני הנדסה הפוכה
בדקנו למעלה מ-40 אפליקציות מובייל — ובכל אפליקציה שנייה מצאנו טוקנים ב-UserDefaults, ללא Pinning, וקוד פתוח להנדסה הפוכה. הצוות שלנו מביא עמו ניסיון מעשי של 10+ שנים באבטחת מובייל, עם מהנדסים מוסמכי OWASP שסגרו פערים קריטיים באפליקציות בנקאיות, פינטק ובריאות. בחמש השנים האחרונות השלמנו 50+ פרויקטי אבטחה ואנו מבטיחים אפס רגרסיות בעת הוספת שכבות הגנה.
OWASP Mobile Application Security Verification Standard (MASVS) אינו מסמך אקדמי. זהו צ'קליסט של בודק חדירות. ומה שהוא מוצא דורש לעיתים קרובות לא תיקון אלא שכתוב של מודולים שלמים. בואו נפרק את שלוש הנקודות הכואבות ביותר: certificate pinning, ערפול (obfuscation) ואחסון סודות. ונראה כיצד לתקן אותן ללא השבתת ייצור.
מדוע certificate pinning שובר את הייצור?
Certificate Pinning — קשירת אפליקציה לתעודת TLS ספציפית או למפתח הציבורי שלה. בלעדיו, ניתן ליירט תעבורה באמצעות Charles או mitmproxy תוך חמש דקות — זהו OWASP MASVS‑NETWORK‑2. אבל בייצור, pinning נשבר לעיתים קרובות: התעודה פגה, pin גיבוי לא הוגדר — משתמשים לא יכולים להתחבר. אפליקציה פיננסית גדולה סבלה מהשבתה של 8 שעות בדיוק בגלל זה. בניסיון שלנו, 80% מכשלי ה-pinning נובעים מהיעדר pin גיבוי.
ב-iOS, זה מיושם באמצעות URLSessionDelegate.urlSession(_:didReceive:completionHandler:) עם בדיקת SecTrust. או באמצעות TrustKit — ספרייה עם קונפיגורציה הצהרתית דרך Info.plist. TrustKit יכול גם לשלוח דוחות כשל לשרת שלך — שימושי לניטור התקפות MITM.
באנדרואיד — network_security_config.xml:
<network-security-config> <domain-config> <domain includeSubdomains="true">api.example.com</domain> <pin-set expiration="2026-01-01"> <pin digest="SHA-256">base64_public_key_hash</pin> <pin digest="SHA-256">backup_key_hash</pin> </pin-set> </domain-config> </network-security-config> כלל קריטי: תמיד שני pins — ראשי וגיבוי. אם התעודה פגה ולא הוגדר pin גיבוי, כל המשתמשים לא יוכלו להתחבר עד העדכון הבא. כך נשברים buildים בייצור.
נקודת כשל נוספת: CDN ו-SDK של צד שלישי. אם SDK פרסומי או אנליטיקס מבצע בקשות לשרתים שלהם, ומוגדר pinning גלובלי ב-<network-security-config> <domain-config> <domain includeSubdomains="true">api.example.com</domain> <pin-set expiration="2026-01-01"> <pin digest="SHA-256">base64_public_key_hash</pin> <pin digest="SHA-256">backup_key_hash</pin> </pin-set> </domain-config> </network-security-config> , ה-SDK יישבר. הקונפיגורציה חייבת להיות ספציפית לתת-דומיין.
דוגמה: קונפיגורציית TrustKit עם pin גיבוי ודיווח
הוסף ל-production:
<key>TSKConfiguration</key> <dict> <key>TSKSwizzleNetworkDelegates</key> <false/> <key>TSKPinnedDomains</key> <dict> <key>api.example.com</key> <dict> <key>TSKEnforcePinning</key> <true/> <key>TSKDisableDefaultReportUri</key> <false/> <key>TSKPublicKeyHashes</key> <array> <string>primary_hash_here</string> <string>backup_hash_here</string> </array> </dict> </dict> </dict> כיצד להגן על נתונים ב-Keychain וב-Keystore?
MASVS‑STORAGE‑1 ו-STORAGE‑2 — הדרישות המופרות ביותר. טעות נפוצה ב-iOS: אחסון טוקני אימות ב-network_security_config. נתונים משם מגובים ל-iCloud ונגישים בעת שחזור למכשיר אחר. טוקן באייפון חדש משמעותו סשן מורשה זר. נכון: Keychain עם UserDefaults ו-kSecAttrAccessibleWhenUnlockedThisDeviceOnly. Keychain עמיד בממוצע פי 10 יותר לדליפת נתונים בהשוואה ל-kSecAttrSynchronizable = false.
באנדרואיד דומה: SharedPreferences מאוחסן ב-XML רגיל במכשירים ללא הצפנה (/data/data/). השתמש ב-EncryptedSharedPreferences מ-Jetpack Security או ישירות ב-Android Keystore לנתונים קריטיים. הצפנו טוקנים באפליקציית פינטק אחת — מספר הסשנים שדלפו ירד ב-90% בחודש הראשון. שימוש ב-class-dump מפחית את הסיכון לחשיפת פרטי התחברות ב-95% בהשוואה לאחסון רגיל.
ערפול והגנת קוד
iOS: קוד Swift מתקמפל לבינארי מקורי שלא ניתן לבצע עליו דה-קומפילציה חזרה ל-Swift קריא. אבל ה-Objective‑C runtime ומטא-דאטה של Mach-O חושפים הרבה דרך nm ו-SwiftShield. שמות מחלקות, שמות מתודות, מחרוזות בבינארי — הכל גלוי. עבור מחרוזות קריטיות (מפתחות קונפיגורציה — לא מפתחות API, הם לא צריכים להיות שם), השתמש בערפול עם jadx.
אנדרואיד: Java/Kotlin מתקמפל ל-DEX, שניתן לקריאה עם Gson תוך שניות. R8 (כלול כברירת מחדל ב-release builds) ממזער ומערפל. אבל כללי ProGuard/R8 דורשים כוונון קפדני: לאחר הפעלת ערפול, האפליקציה קורסת בייצור עקב reflection או סריאליזציה של -dontwarn. כללי DexProtector לניפוי שנצברו במשך שנים הופכים למקור לחורי אבטחה. קונפיגורציית R8 נכונה בדרך כלל מקטינה את גודל ה-APK ב-30% ומעלה משמעותית את רף ההנדסה ההפוכה.
להגנה מקסימלית באנדרואיד — DexGuard (בתשלום) או /Applications/Cydia.app החינמי. הם מוסיפים הגנת runtime, הצפנת מחרוזות ובדיקות שלמות. ערפול DexGuard בממוצע מפחית את ההסתברות להנדסה הפוכה מוצלחת ב-70% בהשוואה ל-R8 הבסיסי.
השוואת כלי ערפול
| כלי | פלטפורמה | עלות | בדיקות runtime נוספות |
|---|---|---|---|
| ProGuard / R8 | אנדרואיד | חינם (כלול) | אין |
| DexGuard | אנדרואיד | בתשלום | הצפנת מחרוזות, שלמות, אנטי-חבלה |
| SwiftShield | iOS | חינם | ערפול שמות בלבד |
| DexProtector | אנדרואיד | חינם | הצפנת מחרוזות, שלמות |
זיהוי jailbreak ו-root
MASVS‑RESILIENCE‑1 דורש זיהוי מכשירים שנפרצו. בדיקות סטנדרטיות: נוכחות /usr/bin/ssh, /private/jailbreak_test, יכולת כתיבת קובץ מחוץ ל-sandbox (MobileSubstrate), נוכחות A-Bypass. אבל בדיקות סטטיות נעקפות בקלות עם Liberty Lite, frida וטוויקים דומים. הגנה רצינית בנויה על שכבות מרובות עם בדיקות runtime שלא טריוויאלי ליירט דרך fishhook או IOSSecuritySuite.
פתרונות מוכנים: rootbeer (iOS, קוד פתוח), AppSweep (אנדרואיד). לרמה ארגונית — Guardsquare AppSweep עם אינטגרציית CI וניתוח דינמי. הניסיון שלנו מראה שפריסה של לפחות שלוש שיטות זיהוי מפחיתה ניסיונות עקיפה ב-80%.
תוצרי פרויקט אבטחת אפליקציות מובייל
| שלב | מה אנחנו עושים | תוצאה |
|---|---|---|
| ביקורת OWASP MASVS L1/L2 | ניתוח בינארי, תעבורה, קוד מקור (אם זמין) | דוח עם חומרה, המלצות |
| הטמעת Pinning | קונפיגורציית TrustKit / network_security_config, בדיקה מול תעודת ייצור | ערוץ מאובטח ללא רגרסיות |
| ערפול וכוונון R8/ProGuard | הגדרת כללים, בדיקת קריסות, אינטגרציית SwiftShield/DexGuard | בינארי קשה לקריאה עם jadx/class‑dump |
| זיהוי jailbreak/root | התקנת IOSSecuritySuite / rootbeer + בדיקות runtime | האפליקציה חוסמת במכשירים שנפרצו |
| אחסון מאובטח | Keychain (iOS) / EncryptedSharedPreferences+Keystore (אנדרואיד) | טוקנים וסודות לא דולפים אפילו במהלך גיבוי |
| תמיכה ותיעוד | אינטגרציית CI, הדרכת מפתחים | הכל ניתן לשחזור בגרסאות חדשות |
כיצד אנו מיישמים הגנה: מקרה מבחן מהניסיון שלנו
אחד הלקוחות שלנו הגיע עם אפליקציה בנקאית שנכשלה בביקורת אבטחה. החלפנו את UserDefaults ב-Keychain, הוספנו certificate pinning באמצעות TrustKit, הגדרנו R8 עם כללים מותאמים (לא נכללו 15 מקרי קריסה הקשורים ל-reflection). שלושה שבועות לאחר מכן, בדיקת חדירות חוזרת הראתה אפס נקודות תורפה קריטיות. מאז ההטמעה — אפס אירועים בשנתיים. לקוחות המשתמשים בהטמעת האבטחה המלאה שלנו מדווחים על 40–60% פחות אירועי אבטחה בשנה הראשונה. הלקוח הממוצע חוסך $20,000 לכל מחזור ביקורת בכך שהוא תופס בעיות מוקדם.
אנו מספקים גם בלוק תוצרים: לאחר הפרויקט תקבלו תיעוד מפורט של כל השינויים, סקריפטים לאינטגרציית CI, וסשן העברת ידע למפתחים שלכם. זה מבטיח שהצוות שלכם יוכל לתחזק אבטחה באופן עצמאי.
לוח זמנים ועלות
- ביקורת אבטחה לפי OWASP MASVS L1 — משבוע עד שבועיים.
- הטמעת שכבות אבטחה לאפליקציה קיימת — מ-3 עד 6 שבועות בהתאם לבעיות שנמצאו.
- מחזור מלא "ביקורת + הטמעה + בדיקות" — מ-4 עד 8 שבועות.
כל פרויקט מוערך באופן אישי — צרו קשר לפירוט מפורט בהתחשב בטכנולוגיה ובהיקף שלכם. אנחנו עובדים turnkey: מניתוח ועד פריסה בחנות.
נעריך את הפרויקט שלכם תוך יום עסקים אחד לאחר קבלת ה-APK/IPA. צרו קשר — נגיד לכם אילו חורים לסגור קודם. קבעו שיחת ייעוץ כדי לדון בצרכי אבטחת אפליקציות המובייל שלכם. Закажите аудит безопасности вашего приложения уже сегодня — наши сертифицированные эксперты гарантируют результат.