עשרת הסיכונים הגדולים ביותר בכתיבת mobile application

שלבים

1. 1

   שלב 1

   
   הסיכון: שמירת מידע מקומי על המכשיר באופן לא מאובטח. עלול להשליך על: איבוד מידע, גניבת זהות וסיסמאות, פרטיות, עמידה בתקנים. בד"כ נובע מהגורמים הבאים: אי הצפנה, caching,הרשאות נרחבות מדי, אי שימוש ב- platform best practice. דוגמא: שימוש באחסון מקומי לשמירת שם וסיסמא אם מסומן "זכור אותי" בהזדהות ליישום. מניעה: שמירת מידע נחוץ בלבד,לא להשתמש בהתקנים ציבוריים כמו sdcard,הצפנה והרשאות מדויקות.
2. 2

   שלב 2

   הסיכון: יישומוני צד שרת חלשים. עלול להשליך על: איבוד מידע, גניבת זהות וסיסמאות, אמינות המידע, עמידה בתקנים. בד"כ נובע מהגורמים הבאים: מתן אמון גדול מידי בתוכנת לקוח. דוגמאות: כל הבעיות של אתרי אינטרנט: xss, csrf injection וכו'. מניעה:למידת ה- owasp top 10 + הבנת הסיכונים הנוספים של יישומי מובייל.
4. 3

   שלב 3

   הסיכון: אי הגנה על התקשורת בתווך. עלול להשליך על: התקפות האזנה, אמינות המידע, גניבת זהות, עמידה בתקנים. בד"כ נובע מהגורמים הבאים: אי הצפנת התקשורת, או הצפנה, אבל התעלמות מהודעות אזהרה. דוגמא:google clientlogon auth protocol. ה- authorization header עובר ב- http, ובהאזנה (sniff) למשל בגישת wifi, השרות חשוף להתחזות. מניעה: לוודא שמידע רגיש הוא מוצפן, ולחנך משתמשים לא להתעלם מהודעות אזהרה !
5. 4

   שלב 4

   הסיכון: הזרקת צד-לקוח - client side injection עלול להשליך על: השתלטות מרוחקת, privilege escalation. בד"כ נובע מהגורמים הבאים: פגיעויות צד שרת כמו xss, html injection. בעיות חדשות: שליחת SMS מהמכשיר, תשלום מהמכשיר, שימוש בחייגן. דוגמא: צד השרת (hybrid app web+clientapp) חשו, ל- XSS, ומורץ javascript שפונה לפונקציונליות ה- SMS במכשיר. מניעה: סניטצית קלט בצד השרת, צמצום השרותים הרגישים שעובדים ב- hybrid.
6. 5

   שלב 5

   הסיכון: הזדהות והרשאות (authentication and authorization ) חלשים. עלול להשליך על: גישה ללא אישור ,privilege escalation. בד"כ נובע מהגורמים הבאים: שימוש בערך חלש כגון מספר מכשיר או uuid לזיהוי. מזההים חומרתי שלא נמחקים. מניעה: שימוש בתשתיות הזדהות של היצרן, ויישום של הזדהות חזקה עם מספר פאקטורים.
7. 6

   שלב 6

   ניהול לא תקין של חיבורים (improper session handling). עלול להשליך על: גישה ללא אישור ,privilege escalation. בד"כ נובע מהגורמים הבאים: נוחות ושימושיות - ה- session id בד"כ ארוך מאד. מניעה: הזדהות מחדש גם באמצע עבודה (למשל בגישה לנתונים חסויים). פיתוח יכולת ביטול session.
8. 7

   שלב 7

   החלטות אבטחה לפי קלטים לא אמינים - (Security Decisions Via Untrusted Inputs) עלול להשליך על: גישה ללא אישור ,privilege escalation, איבוד מידע. בד"כ נובע מהגורמים הבאים: ב- IOS: abusing url schems, באנדרואיד: Abusing Intents דוגמא: יצירת שיחה ללא רצון המשתמש ב- skype ע"י החדרת קוד באתר אינטרנט (עם אייפריים) מניעה: זיהוי המקור בקלטים, הקפצת מסכי אישור נוספים ללקוח, או הזדהויות נוספות לפני ביצוע פעולות רגישות.
9. 8

   שלב 8

   דליפת מידע מערוצים צדדיים - (side channel data leakage) עלול להשליך על: חריגות פרטיות. בד"כ נובע מהגורמים הבאים: שילוב של פיתוח לקוח, ואי ביטול הגדרות פלטפורמה. מידע רגיש משתמש ב- caches, מגיע ל- logs, ספריות זמניות. מניעה: סינון מידע רגיש מלוגים, צילומי מסך. ביצוע debug לפני פרסום, ובדיקת קבצים שנוצרים, לוגים וכו'. בדיקה קפדנית של ספריות צד ג' שבשימוש, בדיקת היישום במספר רב ככל האפשר של פלטפורמות.
10. 9

    שלב 9

    הצפנות לא תקינות - broken cryptography. עלול להשליך על: חריגות פרטיות, privilege escalation, עקיפת business logic. בד"כ נובע מהגורמים הבאים: שימוש ב- encoding, obfuscation, hashing או serialization במקום הצפנה, יישומי הצפנה custom. מניעה: לא לשמור את המפתח יחד עם התוכן המוצפן, שימוש בספריות הצפנה סטנדרטיות, שימוש ב- best practices של הפלטפורמה.
11. 10

    שלב 10

    חשיפת מידע רגיש - sensitive information disclosure. (בניגוד ל -1 זה hardcoded) עלול להשליך על: דליפת קניין רוחני, חשיפת מאפייני הזדהות. בד"כ נובע מהגורמים הבאים: קלות הביצוע של reverse engineering, "אוצרות" שנשמרות מקומית - api keys, סיסמאות, לוגיקה עסקית רגישה. מניעה: שמירת המידע הרגיש על השרת !