ביקורת אבטחה ליישומי מובייל (OWASP Mobile Top 10)
לאחר עדכון של אפליקציית מובייל ב-Google Play או ב-App Store, מתחרים יכולים לקבל גישה לבסיס המשתמשים שלך. או שתוקף מנצל קישור עמוק (deep link) פגיע כדי לאפס סיסמת מנהל. תרחישים אלה נובעים מהיעדר ביקורות אבטחה שיטתיות. המהנדסים שלנו, עם ניסיון מעשי של 5+ שנים ולמעלה מ-100 ביקורות שהושלמו, מוצאים את החולשות האלה לפני שתוקפים עושים זאת.
לפי OWASP, יותר מ-80% מהיישומים הניידים מכילים לפחות פגיעות אחת מתוך Mobile Top 10. תיקון פגיעות במהלך הפיתוח עולה פי 30 פחות מאשר לאחר השחרור. לכן, ביקורת לפני פרסום היא השקעה חכמה. אנו משלבים ניתוח סטטי ודינמי עם בדיקות חדירה ידניות כדי לכסות את כל וקטורי ההתקפה. כך זה עובד.
למה OWASP Mobile Top 10 הוא אמת המידה לבדיקות
ה-OWASP Mobile Top 10 אינו רשימת בדיקה פורמלית אלא גישה מובנית לבדיקות אקטיביות. כל אחד מ-10 הפריטים מותאם לארכיטקטורת היישום: אנחנו לא רק מסמנים פריטים ברשימה—אנחנו משחזרים התקפות בתנאים אמיתיים. כך אנחנו עושים זאת.
איך אנחנו מוצאים פגיעויות: פרטי התהליך
נתחיל במקור הסיכון הנפוץ ביותר: אחסון סודות לא תקין.
M1 ו-M2: סודות, תלותים ושרשרת אספקה
אנחנו מחפשים אישורים מקודדים: מפתחות API בקוד, סיסמאות בקבצי תצורה, טוקנים בהיסטוריית git. כלים: jadx + grep, truffleHog למאגרים, ניתוח של AndroidManifest.xml ו-Info.plist. אנו בודקים אחסון: אישורים ב-SharedPreferences/UserDefaults הם פגיעות. הם צריכים להיות ב-Android Keystore / iOS Keychain. במכשיר שבור (jailbroken) אנו קוראים את Keychain באמצעות objection keychain dump—אנחנו בודקים מה מאוחסן ובאילו תכונות גישה.
תלותים של צד שלישי הם לעתים קרובות החוליה החלשה ביותר. אנו בודקים גרסאות ספריות מול CVEs ידועים (OWASP Dependency-Check, gradle dependencyInsight, pod-outdated), שימוש בספריות לא מהימנות, הרשאות המבוקשות על ידי SDK של אנליטיקה ופרסום. בנפרד, אנו בוחנים את צינור ה-CI/CD: סריקת סודות במאגר, חתימת ארטיפקטים, שלמות תלותים באמצעות אימות hash.
M3 ו-M4: אימות, הרשאות ואימות קלט
אנו בודקים עקיפת מסך התחברות באמצעות קישורים עמוקים (העברת פרמטרים ב-URL שאמורים להיות נגישים רק למשתמשים מאומתים), הסלמת הרשאות אופקית (משתמש מאומת A ניגש לנתונים של משתמש B על ידי שינוי user_id בבקשה), וחוסר אימות מחדש של סשן לפעולות קריטיות.
בפועל, אנו מוצאים לעתים קרובות: קישור עמוק myapp://reset-password?token=XXX מטופל ללא בדיקת מקור ה-intent—כל אפליקציה יכולה לשלוח intent כזה ולגרום לאיפוס סיסמה. או ששינוי אימייל בפרופיל אינו דורש את הסיסמה הנוכחית.
בצד הלקוח הנייד רלוונטי במיוחד: הזרקות SQL דרך פרמטרים של קישורים עמוקים או URLs של WebView, XSS ב-WebView עם setJavaScriptEnabled(true), מעבר נתיבים (path traversal) בעבודה עם קבצים (URL כמו ../../etc/passwd בפרמטרים של העלאת קבצים), ודה-סריאליזציה לא בטוחה ב-Intent extras.
// уязвимый код — принимает Intent extras без валидации
String fileName = getIntent().getStringExtra("file_name");
File file = new File(getExternalFilesDir(null), fileName);
// fileName = "../../../../../../data/data/com.other.app/secret.db" M5 ו-M8: תקשורת ותצורה
אנו בודקים באמצעות פרוקסי Burp Suite: HTTPS מופעל עבור כל נקודות הקצה, הצמדת אישורים (certificate pinning) (עוקפים עם Frida // уязвимый код — принимает Intent extras без валидации String fileName = getIntent().getStringExtra("file_name"); File file = new File(getExternalFilesDir(null), fileName); // fileName = "../../../../../../data/data/com.other.app/secret.db" ), נתונים רגישים בפרמטרי GET (מתועדים על ידי שרתים, פרוקסים, CDNs), חיבורי WebSocket לא מאובטחים, דליפת נתונים רגישים בכותרות בקשה. ssl-unpinning.js באנדרואיד—בדיקת network_security_config.xml, נוכחות של אישורי CA שסופקו על ידי המשתמש ב-trust-anchors.
תצורת אבטחה שגויה: cleartextTrafficPermitted במניפסט הייצור פותח גישת דיבאג. android:debuggable="true" מאפשר android:allowBackup="true" באנדרואיד < 12—מהגיבוי אנו קוראים SharedPreferences, מסדי נתונים. adb backup על רכיבים ללא אימות intent. ב-iOS—ATS (App Transport Security) מושבת באמצעות exported="true". הרשאות (Entitlements): יכולות מוגזמות (לדוגמה, NSAllowsArbitraryLoads באפליקציה שאינה משתמשת ב-iCloud).
M6, M7 ו-M9: נתונים, הגנה על בינארי ואחסון
הרשאות: האפליקציה מבקשת com.apple.developer.icloud-container-identifiers כל הזמן, אבל מיקום גיאוגרפי נחוץ רק בתרחיש ספציפי? או ACCESS_FINE_LOCATION ללא כל פונקציונליות קשורה לאנשי קשר? אנו מנתחים את ההתאמה בין ההרשאות המבוקשות לפונקציונליות המוצהרת. לוגים: READ_CONTACTS חושף לעתים קרובות PII במבני ייצור. אנו בודקים נתונים רגישים ב-logcat, הודעות Crashlytics/Sentry, ואירועי אנליטיקה.
פירוק APK עם adb logcat, IPA עם jadx. הערכה: קריאות של הלוגיקה העסקית לאחר פירוק, נוכחות ואיכות של ערפול (R8/ProGuard/DexGuard), קבועי מחרוזת בטקסט פשוט, דגלי דיבאג במבני ייצור (Ghidra, BuildConfig.DEBUG במניפסט), ובדיקות אנטי-שינוי (anti-tampering).
ביקורת מלאה של אחסון המכשיר:
| אחסון | מה אנחנו מחפשים | כלי |
|---|---|---|
| מסד נתונים SQLite | נתונים רגישים, חוסר הצפנה | debuggable, objection |
| SharedPreferences / UserDefaults | סיסמאות, טוקנים, מפתחות | sqlite3 |
| Keychain (iOS) | תכונות גישה, מה מאוחסן | objection data storage |
| מערכת קבצים | מסמכים לא מוצפנים, מטמון תגובות API | objection keychain dump |
| לוח גזירה (Clipboard) | העתקה אוטומטית של נתונים רגישים | בדיקה ידנית |
M10: קריפטוגרפיה חלשה
אלגוריתמים חלשים: objection files ls, DES, 3DES, RC4 לסיסמאות, מצב MD5 לצפני בלוקים, seed צפוי ב-ECB במקום java.util.Random, IV אפס או קבוע, חוסר MAC (שימוש ב-SecureRandom ללא HMAC). יישומי קריפטוגרפיה מותאמים אישית במקום ספריות סטנדרטיות הם דגל אדום. "קריפטוגרפיה ביתית" היא כמעט תמיד שבורה.
מה הביקורת מספקת: תוצאות ותיעדוף
עבור כל אחת מ-10 הקטגוריות, אנו מתעדים: נמצא/לא נמצא, מקרי פגיעות ספציפיים עם ציוני CVSS, שלבי שחזור, והמלצות לתיקון עם דוגמאות קוד. עדיפויות: קריטי (ניתן לניצול ללא root/jailbreak, גישה ישירה לנתונים) → גבוה → בינוני → נמוך (ממצאים אינפורמטיביים).
איך להתכונן לביקורת: 3 שלבים
- אסוף את קבצי הבינארי הנוכחיים (APK/IPA) ואת קוד המקור אם זמין.
- ספק תיעוד: תיאור ארכיטקטורה, רשימת ספריות צד שלישי, נקודות קצה של API.
- זהה תרחישים קריטיים: אימות, תשלומים, טיפול בנתונים אישיים.
השוואת שיטות בדיקה
| סוג ניתוח | זמן נדרש | עומק כיסוי | שיעור זיהוי פגיעויות |
|---|---|---|---|
| סטטי | 1–2 ימים | קוד + תלותים | 60–70% |
| דינמי | 2–3 ימים | זמן ריצה + רשת | 40–50% |
| בדיקת חדירה ידנית | 3–5 ימים | לוגיקה + עסקים | 80–95% |
בדיקה ידנית מזהה עד 95% מהפגיעויות—30% יותר מאשר סריקה אוטומטית. לכן הביקורת שלנו משלבת את כל שלושת הסוגים.
בפרויקט אחד, גילינו שהאפליקציה אחסנה טוקני OAuth ב-SharedPreferences ללא הצפנה. לאחר ההמלצה שלנו, צוות הפיתוח העביר אותם ל-Android Keystore. התיקון לקח יום אחד ומנע גישה לא מורשית לחשבונות במכשירים עם root.
ביקורת של אפליקציה טיפוסית בקנה מידה בינוני מול OWASP Top 10 אורכת 3–5 ימי עבודה. היא כוללת ניתוח סטטי, בדיקות דינמיות במכשירי אנדרואיד עם root ו-iOS עם jailbreak, וניתוח תעבורה. התוצר הוא דוח לפי מפרט הלקוח. בקשו ייעוץ להערכת האפליקציה שלכם—המומחים שלנו יחזרו אליכם תוך שעה. קבעו ביקורת אבטחה לאפליקציית המובייל שלכם עוד היום.







