בואו נתכנן את הצעד הבא באבטחת הארגון
השאירו פרטים לשיחה
בדיקות חדירות: המדריך והשירות המרכזי / מבדק חדירות לאפליקציות Web
מבדק חדירות לאפליקציות Web בוחן מה אפשר לעשות דרך האתר או המערכת, ולא רק אילו רכיבים מותקנים בה. הבדיקה מתמקדת בהרשאות, בתהליכים עסקיים, בטיפול בנתונים ובקשרים בין המשתמשים לבין השרת. המטרה היא לזהות מצבים שבהם אדם יכול לבצע פעולה או לקבל מידע מעבר למה שהוגדר עבורו, ולתת לצוות הפיתוח בסיס ברור לתיקון.
מבדק חדירה לאתר: מעבר לבדיקת עמוד הכניסה
אתר תדמיתי, חנות מקוונת ומערכת SaaS חושפים משטחי תקיפה שונים. בחנות חשוב להבין הזמנות, תשלום, קופונים והחזרות. במערכת ארגונית נבחנים תפקידים, הפרדת לקוחות ופעולות ניהול. גם אתר שנראה פשוט עשוי לכלול העלאת קבצים, אזור משתמשים או מערכת ניהול שמחוברת לשירותים נוספים. לכן מספר העמודים אינו מדד מספיק להיקף העבודה. ההגדרה צריכה להתייחס לפונקציות, לזרימת הנתונים ולמשאבים שעליהם הן משפיעות. בדיקה של דף הבית בלבד לא מייצגת את אבטחת האפליקציה כולה.
אימות והרשאות: שתי שאלות שונות
אימות עונה על השאלה מי המשתמש. הרשאה עונה על השאלה מה מותר לו לעשות. מערכת יכולה לזהות משתמש היטב ועדיין לאפשר לו לצפות במסמך של אדם אחר או להפעיל פעולה ניהולית. הבדיקה צריכה להתייחס למשתמשים בעלי תפקידים שונים, למשאבים ששייכים ללקוחות שונים ולפעולות שאפשר לבצע על כל משאב. חשוב לבחון את האכיפה בצד השרת, משום שכפתור מוסתר או קישור שאינו מופיע בתפריט אינם מגבלה מספקת. רצוי להכין חשבונות בדיקה נפרדים ונתוני דוגמה שיאפשרו לבחון גבולות בלי לערב מידע אמיתי.
לוגיקה עסקית שאינה מופיעה בסריקה אוטומטית
תהליך עסקי יכול להיות תקין מבחינה טכנית ועדיין לאפשר שימוש שחורג מהכוונה שלו. למשל, מערכת הזמנות עשויה להניח שכל שלב בוצע פעם אחת ובסדר קבוע, או להסתמך על מחיר שהגיע מהדפדפן. אלה תרחישים להמחשה, לא ממצאים על האתר שלכם. במסגרת מבדק נבדקות ההנחות שהמערכת עושה על המשתמש, על סדר הפעולות ועל מצב המידע. צוות הבדיקה צריך להבין את התהליך עם בעלי המוצר, כדי להבדיל בין התנהגות מותרת לבין עקיפה בעלת משמעות עסקית. המטרה היא להגן על כללי התהליך ולא רק על הקוד שמריץ אותו.
קלט, קבצים וגבולות אמון
מידע שנשלח דרך טפסים, פרמטרים וקבצים עובר בין הדפדפן, השרת ושירותים חיצוניים. בוחנים היכן הוא מקבל אמון, כיצד הוא נשמר ואיפה הוא מוצג שוב. העלאת קובץ, לדוגמה, מחייבת התייחסות לסוגי קבצים, למיקום האחסון, להרשאות הגישה ולעיבוד שמתבצע לאחר ההעלאה. גם הודעות שגיאה, ייצוא נתונים וקישורים זמניים עשויים לחשוף מידע שלא נועד למשתמש. בבדיקה מבוקרת משתמשים בדוגמאות בטוחות ובוחנים את התנהגות המערכת בלי להעלות תוכן שעלול לפגוע בה.
מתי צריך להפריד בין Web לבין API?
אפליקציית Web משתמשת לעיתים בממשקי API שמשרתים גם מובייל או שותפים. מבדק Web צריך להבין את הקריאות האלה, אך בדיקה ייעודית של API יכולה להוסיף כיסוי לגרסאות, לממשקים שאינם מופיעים במסך וליחסי אמון בין שירותים. אם ההיקף כולל את שני התחומים, צריך לכתוב זאת במפורש כדי שלא ייווצר פער ביניהם. דף זה מתמקד בחוויית המשתמש ובתהליכי האפליקציה; בדף API מוסבר כיצד לתכנן כיסוי רחב יותר לשכבת הממשקים. בדיקת ענן או רשת עוסקת בשכבות אחרות ואינה מחליפה את בחינת ההרשאות העסקיות.
מה צריך להופיע בתוצאות הבדיקה?
לכל ממצא נדרש הסבר שמחבר בין הרכיב שנבדק לבין התרחיש וההשפעה. ראיות מועילות כוללות תפקיד משתמש, פעולה שנבחנה, תוצאה בפועל והתנהגות שהייתה אמורה להתרחש. ההמלצה צריכה להתייחס למנגנון האכיפה ולהימנע מתיקון נקודתי שמסתיר רק את הדוגמה שנמצאה. לדוגמה, בעיית הרשאות חוזרת עשויה לדרוש מנגנון מרכזי ובדיקות רגרסיה. בזמן בדיקה חוזרת בוחנים גם אם אותו דפוס מופיע בפעולות קרובות, בהתאם להיקף שסוכם. זה מאפשר להשתמש בדוח כחומר עבודה לצוות ולא רק כמסמך שמוגש לביקורת.
איך מתכננים מבדק שאפשר לפעול לפי התוצאות שלו?
מבדק מועיל מתחיל בהגדרת השאלות שהארגון רוצה לקבל עליהן תשובה. האם משתמש יכול להגיע למידע של לקוח אחר? האם גישה מוגבלת מאפשרת התקדמות למערכת קריטית? האם צוות האבטחה מסוגל לזהות פעולה חשודה בזמן? את השאלות האלה מתרגמים להיקף עבודה, לתרחישים ולתוצרים. כך אפשר להבין מה נבדק בפועל, מה נשאר מחוץ לתחום ואילו מגבלות משפיעות על המסקנות. הצעת עבודה טובה מציגה את ההנחות האלה מראש, במקום להשאיר אותן לפרשנות בסיום הפרויקט.
גבולות, הרשאות ותיאום
לפני תחילת הפעילות מגדירים רשימת נכסים, בעלות על המערכות, חשבונות בדיקה, חלון פעילות ואנשי קשר. מגדירים גם פעולות אסורות, ספי עומס ותהליך עצירה במקרה של השפעה לא צפויה. שירות של צד שלישי אינו הופך לחלק מהבדיקה רק מפני שהוא מחובר למערכת שלכם. לכל רכיב נדרשת הרשאה מתאימה. בסביבה פעילה עדיף להשתמש בנתוני בדיקה ובחשבונות ייעודיים, ולתאם מראש כיצד יישמרו ראיות בלי להעתיק מידע אישי או עסקי מעבר לנדרש.
הוכחת השפעה בלי לגרום נזק
הבדיקה מתקדמת ממיפוי להבנת מנגנוני ההגנה ולבחינה מבוקרת של חולשות. כאשר נמצא נתיב אפשרי, המטרה היא לאסוף ראיות שמספיקות כדי להסביר את הסיכון ולתקן אותו. אין צורך להרחיב גישה או להוציא מאגר שלם כדי להראות שבעיית הרשאות קיימת. אפשר להגדיר מראש דוגמת מידע בטוחה ותנאי הצלחה מוסכמים. אם מתגלה ממצא חמור במהלך העבודה, דרך הדיווח וההסלמה צריכה להיות ברורה, כדי שהצוות האחראי יוכל להגיב בלי להמתין לדוח הסופי.
תיעדוף, תיקון ובדיקה חוזרת
בסיום חשוב לחבר בין חומרת הממצא לבין ההקשר של המערכת: רגישות המידע, חשיפה לאינטרנט, הרשאות נדרשות והשפעה תפעולית אפשרית. רשימת חולשות לבדה אינה מספיקה. צוותי הפיתוח והתשתיות צריכים לדעת מהו שורש הבעיה, אילו רכיבים מושפעים ואיך יוכלו לוודא שהתיקון יעיל. בדיקה חוזרת מתייחסת לגרסה ולתצורה המעודכנות, ומבדילה בין ממצא שנסגר, ממצא שנסגר חלקית וממצא שלא ניתן לאמת בגלל שינוי בהיקף או בהנגשת הסביבה.
מה להכין לקראת שיחת תיחום?
כדאי להכין תיאור קצר של המערכת, תרשים רכיבים, רשימת ממשקים ותפקידים, מידע על סביבת הבדיקה ומועד היעד העסקי. אין צורך לשלוח סיסמאות או מידע רגיש בטופס פנייה. בשיחה אפשר לברר אילו חומרים יועברו בערוץ מוסכם, מי מאשר את הפעילות ומי אחראי לתיקונים. אם קיימים ממצאים קודמים, אפשר להשתמש בהם לתכנון העבודה ולזיהוי אזורים שדורשים תשומת לב. אין להסיק מהיעדר ממצאים שהמערכת חסינה; התוצאה משקפת את ההיקף, התנאים והזמן שהוגדרו לבדיקה.
איך מודדים התקדמות לאחר המבדק?
כדאי להגדיר לכל ממצא גורם אחראי, מועד יעד והחלטה מתועדת. לפעמים אפשר לתקן מיד, ולפעמים נדרש שינוי במערכת או תיאום עם ספק. גם במקרה כזה חשוב להבחין בין טיפול בשורש הבעיה לבין אמצעי זמני שמקטין חשיפה. החלטה לדחות תיקון צריכה לכלול הסבר, מגבלה מפצה ומועד בחינה מחדש. כך נשמר הקשר בין הדוח לבין העבודה בפועל, גם כאשר כמה צוותים חולקים אחריות על אותו תהליך.
לאורך הזמן אפשר לעקוב אחר מספר הממצאים הפתוחים לפי חומרה, משך הזמן עד לתיקון וחזרת בעיות מאותו סוג. המדדים האלה מסייעים לזהות צורך בהדרכה, בבקרות פיתוח או בשינוי תצורה. הם אינם מבטיחים שלא יימצאו חולשות חדשות. כאשר מתחלפת גרסה, נוסף ממשק או משתנה מודל ההרשאות, צריך לבחון אם ההיקף הקודם עדיין מייצג את המערכת. בדיקה תקופתית מועילה יותר כאשר היא מתבססת על השינויים שהתרחשו ועל הסיכונים שהארגון רוצה להקטין.
בשיחת הסיכום רצוי להפריד בין מסר להנהלה לבין פירוט לצוותים הטכניים. ההנהלה צריכה להבין את המשמעות ואת סדר העדיפויות; אנשי המקצוע צריכים לקבל ראיות והמלצות שאפשר ליישם. לפני סגירת הפרויקט כדאי לוודא שהדוח הועבר בערוץ מוסכם ושברור מי שומר את החומרים, מי מקבל גישה אליהם ואילו ראיות יימחקו לפי ההסכם. ההנחיות האלה מגינות גם על המידע שנאסף במהלך הבדיקה.
תחומים משלימים שכדאי להכיר
לעיון במסגרת המקצועית: OWASP Web Security Testing Guide. מסגרת מקצועית מסייעת לתכנון; הכיסוי בפועל מוגדר בהצעת העבודה.
נגדיר יחד היקף שמתאים למערכת שלכם
לתמונה הרחבה ולבחירת סוג המבדק, עברו אל שירות בדיקות החדירות של ExploiX. לתיאום שיחת תיחום אפשר לפנות לצוות עם תיאור קצר של המערכת והצורך העסקי.
שאלות נפוצות
מה כולל מבדק חדירות לאפליקציות Web?
ההיקף נקבע לפי המערכת ויכול לכלול אימות, הרשאות, תהליכים עסקיים, טיפול בקלט, קבצים וממשקים מחוברים. יש להגדיר מראש תפקידים וזרימות מרכזיות. בדיקת אתר ציבורי בלבד אינה כוללת אוטומטית אזור ניהול או מערכות צד שלישי.
האם סריקת חולשות מספיקה לאתר?
סריקה יכולה לזהות בעיות מוכרות, אך אינה מבינה באופן מלא את הכללים העסקיים ואת הבעלות על המידע. כשצריך לבדוק הפרדת לקוחות, תהליכים והרשאות, נדרשת גם בחינה ידנית שמותאמת לאפליקציה.
אפשר לבדוק מערכת עם כמה סוגי משתמשים?
כן, בכפוף להרשאה ולהיקף מוסכם. כדאי להכין חשבונות לכל תפקיד וחשבונות השייכים ללקוחות נפרדים. כך אפשר לבדוק מה מותר לכל משתמש לעשות ולבחון את הגבולות בין קבוצות.
האם הבדיקה חייבת להתבצע בייצור?
לא. אפשר להשתמש בסביבה מייצגת עם תצורה וגרסה שמתאימות למערכת הפעילה. אם בודקים בייצור, נדרש תיאום מפורט יותר ושימוש בנתוני בדיקה. הבחירה צריכה להתייחס גם להבדלים בין הסביבות.
מה מקבלים בסיום מבדק חדירה לאתר?
מומלץ להגדיר דוח עם תקציר, היקף, מגבלות, ממצאים, ראיות והמלצות תיקון. אופן ההצגה, שיחת ההסבר והבדיקה החוזרת הם חלקים שכדאי לברר בהצעת העבודה מראש.
מתי מתאים לבצע בדיקה חוזרת?
אחרי שהצוות הטמיע תיקונים בסביבה מוסכמת. הבדיקה החוזרת בוחנת את הממצאים שנכללו בה ואת השפעת השינוי על התרחיש. היא אינה מחליפה מבדק מלא לאחר שינוי מהותי של האפליקציה.