בואו נתכנן את הצעד הבא באבטחת הארגון
השאירו פרטים לשיחה
בדיקות חדירות: המדריך והשירות המרכזי / מבדקי חדירות לאפליקציות מובייל
מבדקי חדירות למובייל בוחנים את האפליקציה במכשיר ואת האופן שבו היא מתקשרת עם שירותי השרת. מידע מקומי, מנגנוני התחברות, הרשאות וזרימות עסקיות יוצרים משטח בדיקה שחורג ממסכי האפליקציה. כדי לקבל תמונה שימושית צריך להגדיר את הפלטפורמות, גרסאות הבנייה, רכיבי השרת וסוגי המשתמשים שנכללים בעבודה.
Android ו-iOS: היקף שמתחיל בגרסת הבנייה
אפליקציה לשתי פלטפורמות יכולה לשתף לוגיקה עסקית, אך לממש אחסון, תקשורת והרשאות בצורה שונה. לכן אין להניח שבדיקה של גרסה אחת מכסה את האחרת. יש להגדיר גרסאות, חבילות התקנה, מנגנון הפצה וסביבת שרת מתאימה. גם הבדלים בין גרסת בדיקה לבין גרסה שמופצת למשתמשים יכולים לשנות את התוצאה. למשל, תצורת ניפוי או שירות בדיקה עשויים להיות שונים מהייצור. הדוח צריך לתעד את הגרסה שנבדקה ואת המגבלות. כאשר שתי הפלטפורמות בהיקף, כדאי להבין אילו רכיבים משותפים ואילו דורשים בחינה נפרדת.
אחסון מקומי ומידע שנשאר במכשיר
אפליקציה עשויה לשמור אסימונים, קבצים, נתוני משתמש או מידע זמני. הבדיקה מתייחסת למה שנשמר, לאופן השמירה ולמשך החיים של המידע. בוחנים גם תרחישים כמו התנתקות, החלפת חשבון או שינוי הרשאה, בהתאם להיקף. מידע שנמחק מהמסך אינו בהכרח נמחק מכל מיקום שבו נשמר. יש להבחין בין צורך עסקי לגיטימי בשמירת מידע לבין חשיפה שאינה נדרשת. איסוף ראיות נעשה עם נתונים ייעודיים, כדי לא להעתיק תוכן של משתמשים אמיתיים. אם נבחנת התנהגות במכשיר עם תנאים מיוחדים, צריך לתעד אותם ולא להציג אותם כמצב של כל מכשיר.
תקשורת, זהות ושירותי backend
האפליקציה היא לקוח של מערכת רחבה יותר. גם אם היא מגבילה פעולה במסך, השירות בצד השרת צריך לאכוף את ההרשאות בעצמו. במסגרת המבדק בוחנים את הקשר בין התחברות, אסימוני גישה ופעולות בשרת. צריך להגדיר אם הממשקים עצמם נמצאים בהיקף ובאיזו רמת כיסוי. בדיקת תקשורת מתייחסת להגנה על המידע בדרך ולגבולות האמון, אך אינה מחליפה את בדיקת הרשאות המשאבים. אם קיימים שירותי צד שלישי, בוחנים את השילוב שבשליטת הארגון ולא את הספק עצמו ללא הרשאה.
קישורים, רכיבים והרשאות מערכת
אפליקציות משתמשות לעיתים בקישורים עמוקים, ברכיבים שמקבלים קלט מבחוץ ובהרשאות של מערכת ההפעלה. הבדיקה מתייחסת לדרך שבה קלט כזה מגיע לזרימה העסקית ולפעולות שהאפליקציה מבצעת בעקבותיו. חשוב להבין איזה מידע מתקבל מרכיב אחר ואיזה מידע האפליקציה חושפת. הרשאה למצלמה או לאחסון, לדוגמה, צריכה להיות מוצדקת לפי התפקיד שלה במוצר. בוחנים גם מה קורה כשהמשתמש אינו נותן הרשאה. המטרה היא להגן על הגבולות בין אפליקציות, בין משתמשים ובין פעולות, בלי להניח שהפעלה של מסך מעידה על הרשאה עסקית.
ניתוח סטטי, בדיקה בזמן ריצה ולוגיקה עסקית
ניתוח של חבילת האפליקציה יכול לסייע להבין רכיבים ותצורה. בחינה בזמן ריצה מראה כיצד האפליקציה מתנהגת עם משתמשים ונתונים בפועל. שני סוגי הבדיקה משלימים זה את זה, והערך שלהם תלוי בהיקף ובזמינות הסביבה. בדיקה ידנית של תהליכים עסקיים מוסיפה הבנה שאינה מתקבלת מרשימת התראות כלי בלבד. מסגרות כמו OWASP MASVS מספקות שפה משותפת לדרישות אבטחה, אך השימוש בהן אינו מהווה אישור גורף לאבטחת האפליקציה. יש להגדיר אילו תחומים נבחנים, מה לא נבדק ואילו ממצאים אומתו.
תיקון, הפצה ובדיקה חוזרת
תיקון במובייל יכול לדרוש גרסה חדשה של האפליקציה, שינוי בשירות השרת או שניהם. חשוב להבחין מי אחראי לכל רכיב ואיך נמדדת סגירת הממצא. כשמשתמשים מחזיקים גרסאות ישנות, שינוי בצד השרת עשוי להיות חלק משמעותי מההגנה. לפני בדיקה חוזרת מבררים מה נפרס ואילו גרסאות עדיין נתמכות. ממצא שנפתר בבנייה חדשה אינו אומר בהכרח שכל משתמש קיבל אותה. הדוח צריך להיות ברור לגבי הגרסה שנבדקה ולהציג את התנאים שבהם התיקון יעיל. בדיקת API משלימה יכולה לסייע לכסות שירותים שמשמשים כמה לקוחות שונים.
איך מתכננים מבדק שאפשר לפעול לפי התוצאות שלו?
מבדק מועיל מתחיל בהגדרת השאלות שהארגון רוצה לקבל עליהן תשובה. האם משתמש יכול להגיע למידע של לקוח אחר? האם גישה מוגבלת מאפשרת התקדמות למערכת קריטית? האם צוות האבטחה מסוגל לזהות פעולה חשודה בזמן? את השאלות האלה מתרגמים להיקף עבודה, לתרחישים ולתוצרים. כך אפשר להבין מה נבדק בפועל, מה נשאר מחוץ לתחום ואילו מגבלות משפיעות על המסקנות. הצעת עבודה טובה מציגה את ההנחות האלה מראש, במקום להשאיר אותן לפרשנות בסיום הפרויקט.
גבולות, הרשאות ותיאום
לפני תחילת הפעילות מגדירים רשימת נכסים, בעלות על המערכות, חשבונות בדיקה, חלון פעילות ואנשי קשר. מגדירים גם פעולות אסורות, ספי עומס ותהליך עצירה במקרה של השפעה לא צפויה. שירות של צד שלישי אינו הופך לחלק מהבדיקה רק מפני שהוא מחובר למערכת שלכם. לכל רכיב נדרשת הרשאה מתאימה. בסביבה פעילה עדיף להשתמש בנתוני בדיקה ובחשבונות ייעודיים, ולתאם מראש כיצד יישמרו ראיות בלי להעתיק מידע אישי או עסקי מעבר לנדרש.
הוכחת השפעה בלי לגרום נזק
הבדיקה מתקדמת ממיפוי להבנת מנגנוני ההגנה ולבחינה מבוקרת של חולשות. כאשר נמצא נתיב אפשרי, המטרה היא לאסוף ראיות שמספיקות כדי להסביר את הסיכון ולתקן אותו. אין צורך להרחיב גישה או להוציא מאגר שלם כדי להראות שבעיית הרשאות קיימת. אפשר להגדיר מראש דוגמת מידע בטוחה ותנאי הצלחה מוסכמים. אם מתגלה ממצא חמור במהלך העבודה, דרך הדיווח וההסלמה צריכה להיות ברורה, כדי שהצוות האחראי יוכל להגיב בלי להמתין לדוח הסופי.
תיעדוף, תיקון ובדיקה חוזרת
בסיום חשוב לחבר בין חומרת הממצא לבין ההקשר של המערכת: רגישות המידע, חשיפה לאינטרנט, הרשאות נדרשות והשפעה תפעולית אפשרית. רשימת חולשות לבדה אינה מספיקה. צוותי הפיתוח והתשתיות צריכים לדעת מהו שורש הבעיה, אילו רכיבים מושפעים ואיך יוכלו לוודא שהתיקון יעיל. בדיקה חוזרת מתייחסת לגרסה ולתצורה המעודכנות, ומבדילה בין ממצא שנסגר, ממצא שנסגר חלקית וממצא שלא ניתן לאמת בגלל שינוי בהיקף או בהנגשת הסביבה.
מה להכין לקראת שיחת תיחום?
כדאי להכין תיאור קצר של המערכת, תרשים רכיבים, רשימת ממשקים ותפקידים, מידע על סביבת הבדיקה ומועד היעד העסקי. אין צורך לשלוח סיסמאות או מידע רגיש בטופס פנייה. בשיחה אפשר לברר אילו חומרים יועברו בערוץ מוסכם, מי מאשר את הפעילות ומי אחראי לתיקונים. אם קיימים ממצאים קודמים, אפשר להשתמש בהם לתכנון העבודה ולזיהוי אזורים שדורשים תשומת לב. אין להסיק מהיעדר ממצאים שהמערכת חסינה; התוצאה משקפת את ההיקף, התנאים והזמן שהוגדרו לבדיקה.
איך מודדים התקדמות לאחר המבדק?
כדאי להגדיר לכל ממצא גורם אחראי, מועד יעד והחלטה מתועדת. לפעמים אפשר לתקן מיד, ולפעמים נדרש שינוי במערכת או תיאום עם ספק. גם במקרה כזה חשוב להבחין בין טיפול בשורש הבעיה לבין אמצעי זמני שמקטין חשיפה. החלטה לדחות תיקון צריכה לכלול הסבר, מגבלה מפצה ומועד בחינה מחדש. כך נשמר הקשר בין הדוח לבין העבודה בפועל, גם כאשר כמה צוותים חולקים אחריות על אותו תהליך.
לאורך הזמן אפשר לעקוב אחר מספר הממצאים הפתוחים לפי חומרה, משך הזמן עד לתיקון וחזרת בעיות מאותו סוג. המדדים האלה מסייעים לזהות צורך בהדרכה, בבקרות פיתוח או בשינוי תצורה. הם אינם מבטיחים שלא יימצאו חולשות חדשות. כאשר מתחלפת גרסה, נוסף ממשק או משתנה מודל ההרשאות, צריך לבחון אם ההיקף הקודם עדיין מייצג את המערכת. בדיקה תקופתית מועילה יותר כאשר היא מתבססת על השינויים שהתרחשו ועל הסיכונים שהארגון רוצה להקטין.
בשיחת הסיכום רצוי להפריד בין מסר להנהלה לבין פירוט לצוותים הטכניים. ההנהלה צריכה להבין את המשמעות ואת סדר העדיפויות; אנשי המקצוע צריכים לקבל ראיות והמלצות שאפשר ליישם. לפני סגירת הפרויקט כדאי לוודא שהדוח הועבר בערוץ מוסכם ושברור מי שומר את החומרים, מי מקבל גישה אליהם ואילו ראיות יימחקו לפי ההסכם. ההנחיות האלה מגינות גם על המידע שנאסף במהלך הבדיקה.
תחומים משלימים שכדאי להכיר
לעיון במסגרת המקצועית: OWASP Mobile Application Security Verification Standard. מסגרת מקצועית מסייעת לתכנון; הכיסוי בפועל מוגדר בהצעת העבודה.
נגדיר יחד היקף שמתאים למערכת שלכם
לתמונה הרחבה ולבחירת סוג המבדק, עברו אל שירות בדיקות החדירות של ExploiX. לתיאום שיחת תיחום אפשר לפנות לצוות עם תיאור קצר של המערכת והצורך העסקי.
שאלות נפוצות
האם צריך לבדוק בנפרד Android ו-iOS?
כאשר שתי הפלטפורמות נכללות במוצר, יש להגדיר כיסוי לכל אחת. חלק מהלוגיקה משותף, אך מימושי אחסון, תקשורת ורכיבי מערכת יכולים להיות שונים.
האם הבדיקה כוללת את השרת?
רק אם רכיבי השרת והממשקים נכללים במפורש. יש לתאם את הכיסוי כדי שלא להשאיר פער בין בדיקת האפליקציה במכשיר לבין הרשאות בצד השירות.
מה צריך לספק לצוות הבדיקה?
חבילות התקנה מוסכמות, גרסאות, סביבת שרת, חשבונות לפי תפקיד ונתוני בדיקה. מידע על תהליכים מרכזיים מסייע לתכנן בחינה שמתאימה למוצר.
האם MASVS הוא תעודת אבטחה?
MASVS הוא תקן דרישות לאימות אבטחת מובייל. שימוש בו לתכנון אינו מעניק אוטומטית תעודה ואינו מבטיח היעדר חולשות. הדוח צריך לפרט את הכיסוי בפועל.
איך בודקים מידע רגיש בלי לחשוף אותו?
משתמשים במידע ייעודי ובהיקף ראיות מצומצם. מגדירים מראש שמירה, העברה ומחיקה של חומרי הבדיקה. אין צורך להשתמש בנתוני משתמשים אמיתיים כדי להדגים כל תרחיש.
מתי לבצע בדיקה חוזרת למובייל?
לאחר שינוי בגרסת האפליקציה או בשירות הרלוונטי. יש לציין אילו גרסאות נבדקות ולבחון אם התמיכה בגרסאות קודמות משפיעה על סגירת הממצא.