בדיקות חדירה לאפליקציות ווב: זיהוי וניצול חולשות

בדיקת חדירה לאפליקציית ווב: היכן בדיוק נשברת ההגנה

תקיפה על אפליקציית ווב רק לעיתים נדירות מתחילה בפריצה מתוחכמת. לעיתים די לשלוח לשדה בטופס מחרוזת עם תווי שליטה או להחליף פרמטר בבקשה — והאפליקציה עצמה מוסרת את מה שאסור למשתמש לראות. קלט לא מעובד מוביל להזרקת פקודות, לעקיפת שאילתות למסד הנתונים ולקריאת קבצים בשרת.

תרחיש טיפוסי שני — בדיקת הרשאות חלשה. הממשק מצייר כפתורים לפי תפקיד, אבל צד השרת סומך על מזהה מהבקשה: שינוי מספר הזמנה או פרופיל בשורת הכתובת חושף נתונים של אחרים. יש לבדוק הפרדת גישות בכל פעולה, ולא רק בכניסה לאזור האישי — בבדיקת חדירה אי-התאמות כאלה מתגלות ראשונות.

שכבה שלישית — תלויות ולוגיקה מיושנות. ספרייה עם חולשה חשופה בתלות עקיפה נשארת בפרויקט שנים, כי לא קוראים לה ישירות. חלק מהפגמים כלל לא דורשים פריצה: החלפת מחיר בשדה נסתר, קריאה חוזרת לחיוב, עקיפת מונה ניסיונות. זהו סוג של חולשות באפליקציות ווב שסורק לא יראה — הוא לא יודע איך הלוגיקה שלכם תוכננה.

לכן בדיקת אבטחת האתר בנויה כעבודה ידנית לאורך שרשראות: סיור, מיפוי נקודות כניסה, הסלמת הרשאות, גישה לנתונים, הערכת נזק. בדיקת חדירה כזו לאפליקציית ווב מספקת צעדים משוחזרים ותעדוף תיקונים — קודם סוגרים את מה שבאמת מוביל לנתונים של אחרים.

מה נותנת בדיקת חדירה: תוצאות מדידות

בדיקת חדירה חשובה לא ברשימת הממצאים, אלא בשינוי מדדים מדידים. לפני ההתחלה אנחנו קובעים קו בסיס: כמה זמן עובר מהתראת חריגה ועד חסימה, איזה שיעור מהממצאים נסגר במחזור תיקונים אחד, אילו סוגי כשל חוזרים מגרסה לגרסה. אחרי העבודה אותם מדדים נמדדים שוב — ההפרש הוא האפקט של בדיקת חדירה לאפליקציית ווב.

המתודולוגיה — OWASP Testing Guide: אנחנו מכסים אימות, הפרדת הרשאות, עבודה עם סשנים, עיבוד קלט וקונפיגורציה של צד השרת. כל ממצא מתואר לא בסימון «קריטי», אלא בתרחיש ניצול ובצעדים לשחזור — המפתח סוגר את הסיבה, לא את הסימפטום.

התוצאה המרכזית — סוג כשל שהוסר. כשהתיקון נעשה ברמת מנגנון בדיקת ההרשאות או ולידציית הקלט המשותף, מהדוח נעלמת קטגוריה שלמה: ריצה חוזרת של אותם תרחישים לא מוצאת וריאנטים קרובים. בסך הכול זהו הפחתת סיכונים באפליקציית ווב, מבוטאת במספרים.

האפקט השני — זמן תגובה לאירוע. עם תרחיש משוחזר, מהנדס תורן משווה את אות הניטור לתבנית מוכרת וחוסם אותו בדקות במקום שעות של אבחון. את התרחישים האלה אנחנו מעבירים לכללי זיהוי, ולכן ההגנה ממשיכה לעבוד גם אחרי סיום העבודה.

פורמטים של בדיקה: היקף חיצוני, רשת פנימית, תרחיש ממוקד

פורמט הבדיקה נבחר לפי מודל האיום: מאיזו עמדה התוקף רואה את המערכת ומה כבר ידוע לו. ביקורת היקף חיצונית משחזרת את עבודתו של תוקף זר — בלי גישות וקוד מקור, רק כתובות פומביות. רשת פנימית נבדקת מעמדת עובד שנפרץ, ותרחיש תקיפה ממוקד — עם גישה מלאה לקוד ולנתונים.

ככל שמועברים יותר חומרים, כך הבדיקה עמוקה יותר ועבודת המהנדסים ארוכה יותר. קופסה שחורה נותנת תמונה הוגנת של ההגנה החיצונית, אפורה ולבנה חוסכות זמן ומאפשרות להגיע ללוגיקה. את מערך הבדיקות אנחנו משווים למתודולוגיית OWASP.

השוואת פורמטים

בפועל משלבים בין הפורמטים: היקף חיצוני מראה מה זמין מבחוץ, תרחיש ממוקד — במה מסתיימת השרשרת. אין טעם לאחד אותם לשלב אחד: עמדת תצפית שונה נותנת ממצאים שונים.

שלבי העבודה: מתיאום גבולות ועד מסירת תוצאות

בדיקת חדירה לאפליקציית ווב היא לא הרצה חד-פעמית של סורק, אלא מחזור מנוהל עם סדר צעדים קבוע. לפני ההתחלה אנחנו מתאמים את גבולות הבדיקה, חלון הבדיקות ואחראים משני הצדדים: בלי זה כל ממצא יהיה שנוי במחלוקת, והעבודה — סיכון לשירות הפעיל.

1. תיאום גבולות הבדיקה. קובעים רשימה של דומיינים, תתי-דומיינים, ממשקי תוכנה ופאנלים של מנהלים שנכנסים להיקף, ואת מה שנשאר מחוצה לו: שערי תשלום חיצוניים, שירותים של אחרים, נתוני ייצור. בנפרד מסכמים כללים לטיפול במידע שנמצא.
2. חלון בדיקות ומצב עומס. מגדירים מרווחי עבודה, עוצמת בקשות מותרת, איש קשר תורן בצד הלקוח ואות עצירה לעצירה מיידית, אם התנהגות השירות תסטה מהרגיל.
3. סיור ובניית מפת האפליקציה. אוספים נתיבים, תפקידים, נקודות כניסה, תלויות חיצוניות. המפה משמשת בסיס לדוח — לפיה רואים אילו אזורים נבדקו ואילו לא.
4. בדיקה לפי קטגוריות. אימות ושחזור גישה, הפרדת הרשאות בין תפקידים, עיבוד קלט משתמש, עבודה עם סשנים, קונפיגורציה של צד השרת.
5. ניצול ממצאים מאומתים. החולשה מוכחת עם נזק מינימלי: שחזור שלב-אחר-שלב, ארטיפקטים, הערכת חומרה ומה בדיוק זמין לתוקף.
6. מסירת תוצאות. דוח עם תעדופים, צעדים משוחזרים והמלצות לתיקון, ובנוסף סקירה עם צוות הפיתוח שלכם.
7. בדיקה חוזרת של ממצאים. אחרי תיקונים אנחנו חוזרים רק לסעיפים שנסגרו ומאשרים את התוצאה — אחרת אי אפשר להבדיל בין חולשה שהוסרה לחולשה שהוסוותה.

מודל איומים, תפקידי גישה וסגמנטציה: מה נשאר אצל הלקוח

דוח עם חולשות שנמצאו לא מפחית סיכון בעצמו: אחרי רבעון הוא מתיישן, והצוות כבר לא זוכר למה נוצר כלל כזה או אחר. לכן בדיקת חדירה לאפליקציית ווב מסתיימת לא ברשימת הערות, אלא בסט ארטיפקטים עובדים שחיים לצד הקוד ומתעדכנים יחד איתו. להלן מה בדיוק נשאר אצל הלקוח ואיך להשתמש בזה בלעדינו.

• תרשים מודל איומים. נכסים, גבולות אמון, תרחישי תקיפה סבירים והבדיקות שסוגרות אותם; נבחן מחדש כשמשתנה הארכיטקטורה.
• מטריצת תפקידי גישה. מי מורשה לאיזה נתונים, היכן ההרשאות עודפות, אילו קשרים להסיר — הטבלה הופכת לבסיס להפרדת גישות.
• מדיניות גישה. משך חיים של סודות, סדר רוטציה והרשאות מינימליות נדרשות לחשבונות שירות, אינטגרציות ופאנלים של מנהלים.
• נוהל תגובה. מה לתעד, למי לדווח ובאיזה סדר לבודד צומת בחשד לפשרה.
• הוראות שחזור. צעדים ותגובת מערכת צפויה, כדי שהמפתח עצמו יאשר שהסגירה עבדה, ולא יסתמך על מילה.
• תיעוד לפי תוצאות הבדיקה. חומרת הממצאים, סטטוס תיקונים, סיכון שיורי ותאריך הבדיקה הבאה.

כל מסמך אנחנו כותבים עבור הסטאק שלכם ותהליך השחרור שלכם, עם ציון הבעלים והנקודה שבה הוא מתעדכן. כך בדיקה חד-פעמית הופכת למעגל בקרה מתוחזק, ולא לדוח שנקרא פעם אחת.

מקרה בוחן: סגרנו סוג תקיפות בהיקף תשלומים

היקף התשלומים עבד על Stripe, וההרשאות בו נבדקו בצד הממשק: כפתור ההחזר נראה רק לבעל התשלום, אבל השירות קיבל מזהה פעולה מגוף הבקשה וסמך עליו.

בבדיקת החדירה זה נתן עקיפת הרשאה ישירה: החלפת שדה אחד גרמה לבקשה לצאת בשם סשן אחר ולעבור — אפשר היה ליזום החזר או אישור על תשלום של אחר.

מה שינינו בבדיקת ההרשאות

הבעלות הועברה לשכבת השירות: כעת כל קריאה בהיקף משווה בין סובייקט הסשן לבעל הפעולה, ומזהים מהבקשה כבר לא נחשבים הוכחה לזכות. נקודת ההרשאה היא אחת ופועלת לפני הלוגיקה העסקית, ולכן אי אפשר להוסיף מטפל חדש תוך עקיפת הבדיקה. החלטות גישה נכתבות ליומן ביקורת עם סובייקט, פעולה ותוצאה — בירור אירוע אורך דקות.

איך מדדנו את התוצאה

לפני התיקונים, בדיקת בעלות הייתה ל-12 מטפלים מתוך 40 בהיקף. אחרי — לכולם, וזה מעוגן לא בדוח, אלא במערך רגרסיה של 60 תרחישי עקיפה: החלפת מזהה, סשן זר, בקשה חוזרת, סדר קריאות שונה. המערך רץ בכל בנייה, ולכן חזרה של סוג התקיפות נתפסת לפני עלייה לאוויר.

בדיקת חדירה חוזרת לפי אותו תרחיש לא הניבה ממצאים: ניסיון עקיפה נתקל בסירוב לפני ביצוע הלוגיקה העסקית ונשאר ביומן הביקורת. מהירות הפיתוח לא נפגעה — בדיקת הבעלות הפכה להתנהגות ברירת מחדל, ולא למשימה נפרדת בכל שיפור.

מה לעשות אם בדיקת חדירה כבר בוצעה והממצאים לא נסגרו

בדיקת חדירה חוזרת לא מתחילה מאפס. קודם אנחנו משווים את מרשם הממצאים הקודם למצב הנוכחי של האפליקציה: משחזרים את הווקטור המקורי על עותק מעודכן וקובעים אם הוא סגור או רק הוסווה. חיפוש חולשות חדשות מתחיל אחרי זה — אחרת הלקוח משלם על עבודה שכבר נעשתה.

ממצא נחשב סגור רק לפי שחזור. אם הבקשה המקורית כבר לא עוברת, אבל נמצא נתיב עקיפה, הסטטוס נשאר «פתוח». לכן לכל שורה בדוח יש שני אישורים: מה בדיוק שונה בקוד או בקונפיגורציה ובמה זה נבדק.

סדר כזה מסיר תשלום כפול על אותו דבר: בדיקה חוזרת של ממצאים תופסת רק חלק מבדיקת החדירה החוזרת, והכיסוי נשאר מלא. חולשות שלא נסגרו מקבלות תעדוף לפי סיכון שיורי, ולא לפי חומרה פורמלית מדוח ישן.

בסיום — מרשם ממצאים עם סטטוסים, סיכון שיורי ומועד סגירה, ובנוסף אישור תיקונים. זהו מסמך עבודה גם לפיתוח וגם לבדיקה הבאה.

ספקות טכניים: שאלות של מהנדסים ומחלקת אבטחה

לפני ההתחלה אנחנו מקיימים שיחה טכנית עם מהנדסים ומחלקת אבטחה — בה עולות אותן חמש שאלות. אנחנו עונים עליהן מראש, כדי שעד לתיאום המסגרת לא יישארו אי-בהירויות: לא לגבי עומס על היקף הייצור ולא לגבי הצד המשפטי.

מה לעשות עם רכיבי צד שלישי שאין לנו קוד מקור שלהם?

אנחנו מתעדים רשימה מלאה של ספריות ושירותים חיצוניים, ועבור כל אחד בודקים חולשות ידועות והגדרות. במקום שאין קוד מקור, אנחנו מעריכים התנהגות לפי סימנים עקיפים ומסמנים בכנות אזורים עיוורים בפרק נפרד בדוח.

איך תוכיחו שהחולשה באמת מנוצלת?

כל ממצא מאומת בתרחיש משוחזר: רצף צעדים, בקשה ותגובה, הקלטת מסך או קטע מיומן. ממצאים בלי אימות עוברים לפרק «דורש בדיקה נוספת» ולא מתערבבים עם מאומתים.

זה חוקי — תתקפו את המערכת שלנו?

העבודה מתבצעת רק לאחר אישור בכתב מבעל המערכות ובגבולות מתואמים בהחלט: רשימת כתובות, חלונות זמן, אזורים אסורים. שירותים חיצוניים ופלטפורמות של אחרים לא נפגעים, וחריגה מהמסגרת — תיאום בכתב נפרד.

אפשר לעצור את העבודה תוך כדי ומה יקרה עם הגישות?

כן, בצד שלכם נשאר איש קשר לעצירה חירום — העבודה נפסקת מיד. חשבונות בדיקה וגישות שניתנו נשללים בסיום, את הדוח מוסרים באופן סגור, ומסלול הבדיקה מתאמים מראש.

נדון במשימה ובגבולות הבדיקה

בדיקת חדירה לאפליקציית ווב מתחילה לא בהרצת סורק, אלא בתיאום גבולות: מה נכנס לבדיקה, עם אילו הרשאות אנחנו עובדים ואילו תרחישים אסור לגעת בהם. בלי זה ההערכה יוצאת או מוגזמת — «ליתר ביטחון נבדוק הכול», או חלקית, כשהצומת המעניין ביותר נשאר מחוץ להיקף.

כדי לחזור עם הערכה ותוכנית עבודה, אנחנו צריכים מכם:

• רשימת דומיינים, ממשקי שירות ונקודות כניסה למובייל בגבולות הבדיקה — ורשימה מפורשת של מה שנשאר בחוץ.
• גישות: חשבונות בדיקה לכל תפקיד, כולל מנהל, כניסת אורח ושחזור סיסמה.
• מגבלות: חלונות מוגדרים, שיטות אסורות, היקפי תשלום לבדיקה במקום ייצור, עוצמת בקשות מותרת.
• תעדופים: אילו צמתים קריטיים — כניסה למערכת, תשלום, העלאת קבצים, תחלופה עם שירותים חיצוניים.
• נתונים: עותק של מסד הנתונים או ערכות מוסוות, כדי שהבדיקה לא תשנה רשומות משתמש אמיתיות.
• אנשי קשר של האחראי והמהנדס התורן בזמן העבודה וסדר התקשרות בממצא קריטי.
• ארגוני: האם צריך ליידע את ספק התשתית והאם יש נסיגת קונפיגורציה מוכנה.

בתגובה אתם מקבלים תוכנית עבודה לפי שלבים עם חלונות, רשימת תרחישים לבדיקה וכללי עצירה: אם ממצא דורש התערבות מיידית, אנחנו יוצרים קשר עם התורן, ולא ממשיכים בשקט. תארו את המשימה והגבולות — נחזור עם הערכה ותוכנית; ההכנה להתחלה אורכת שיחת תיאום קצרה אחת.