סייבר ואבטחת מידע · web-api-pt

מתודולוגיית Web Application Penetration Testing לפי OWASP WSTG

מאת תאיר מלכא 6 דק׳ קריאהפורסם: 5 באוגוסט 2026

המחשה חזותית מקצועית בנושא Web Application Penetration Testing בתחום Web ו-API PT

תשובה מהירה

בדיקת חדירות אפליקטיבית מתחילה בהגדרת היקף ומיפוי המערכת, וממשיכה בבדיקת בקרות אבטחה ותרחישים עסקיים. OWASP WSTG משמש מסגרת לבחירת בדיקות רלוונטיות; הוא אינו רשימה שמבטיחה כיסוי של כל חולשה אפשרית.

בדיקת אבטחת Web ו-API צריכה לבחון את גבולות האמון, ההרשאות, הקלט, ה-State והלוגיקה העסקית. כל בדיקה במאמר מיועדת למעבדה, CTF או מערכת שניתנה לגביה הרשאה מפורשת. המאמר הנוכחי מתמקד ב-Web Application Penetration Testing ומיועד לתלמידי Web PT ו-Junior Pentesters. המטרה היא לתת שיטת עבודה שאפשר ליישם בתרגול, בראיון מקצועי ובסביבת עבודה, בלי להסתפק בהגדרה מילונית.

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

התרחיש המעשי במאמר הוא: בניית Test plan ל-OWASP Juice Shop במעבדה. כל הדוגמאות הן נתוני מעבדה או תיאור תהליכי. כאשר מדובר ב-Penetration Testing, Web או Cloud, יש לעבוד רק עם אישור מפורש, Scope מוגדר ויכולת לעצור את הבדיקה.

Pre-engagement ו-Test plan

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

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

Information gathering ו-Configuration

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

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

Identity, Authentication ו-Authorization

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

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

Session, Input validation ו-Business logic

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

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

רוצים שנבדוק את אפליקציית ה־Web שלכם? לשירות בדיקות החדירות האפליקטיביות של HPI Cyber

Evidence, Reporting ו-Retest

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

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

מוקדי בדיקה ייחודיים

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: Role ו-session, Endpoint ו-method, Request/Response, Object identifier, Server-side effect, Control expected ו-remediation. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

Role ו-session: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
Endpoint ו-method: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
Request/Response: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
Object identifier: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
Server-side effect: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
Control expected ו-remediation: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

תהליך עבודה מומלץ

הגדירו Scope ושאלת עבודה אחת בנושא Web Application Penetration Testing.
רשמו את מקורות הנתונים והראיות הדרושים: Role ו-session, Endpoint ו-method, Request/Response, Object identifier.
צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

התרחיש שנבחר הוא בניית Test plan ל-OWASP Juice Shop במעבדה. מטרת התרגיל אינה להוכיח יכולת תקיפה, אלא לתרגל איסוף, השוואה ותיעוד בצורה בטוחה. לפני תחילת העבודה מגדירים נתונים מדומים, חלון זמן ותוצאה צפויה.

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

שלב	מה מבצעים	תוצר
הכנה	הגדירו Scope, זמן ויעד. רשמו אילו שדות או ראיות מתוך Role ו-session, Endpoint ו-method, Request/Response צפויים להופיע.	תוכנית בדיקה קצרה
יצירת נתון	בצעו פעולה בטוחה ומדומה הקשורה ל-Web Application Penetration Testing, ללא מידע אמיתי או השפעה על מערכת ייצור.	אירוע/Request/Flow מבוקר
איסוף	אספו את הראיה הגולמית ואת ההקשר ממקור נוסף. ודאו Time zone, מזהים ושלמות.	שתי ראיות מקושרות
ניתוח	כתבו מה כל ראיה מוכיחה, מה אינה מוכיחה ומהו ההסבר הלגיטימי האפשרי.	מסקנת ביניים
סיום	בחרו סגירה, הסלמה, Finding או Tuning; הוסיפו המלצה ו-Retest.	תוצר מתועד

Checklist מעשי

בדקו ותעדו: Role ו-session.
בדקו ותעדו: Endpoint ו-method.
בדקו ותעדו: Request/Response.
בדקו ותעדו: Object identifier.
בדקו ותעדו: Server-side effect.
בדקו ותעדו: Control expected ו-remediation.
ציינו Time zone, גרסת כלי ושעת איסוף.
שמרו את הנתון הגולמי לפני סינון או שינוי.
כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
הגדירו בעלים ופעולת המשך עם מועד.

טעויות נפוצות

לבדוק רק Status code.
להסתמך על שינוי Client-side.
להשתמש ב-Payload מסוכן.
לא לבדוק Roles שונים.
להתעלם מלוגיקה עסקית.
לדווח בלי Request/Response נקיים.

סיכום ו-CTA

מתודולוגיית Web Application Penetration Testing לפי OWASP WSTG הוא נושא שמחבר ידע טכני למשמעת עבודה. התחילו משאלה, אספו רק ראיות רלוונטיות, שמרו הקשר וזמן, ובחרו פעולה שאפשר להצדיק ולבדוק מחדש.

במסלול Cybersecurity & AI של HPI מתרגלים את העקרונות האלה באמצעות מערכות, לוגים ומעבדות. המשך טבעי הוא לעבור למאמרים המקושרים, לבצע את תרגיל המעבדה ולשמור את התוצר כחלק מתיק עבודות מקצועי.

שאלות ותשובות

האם מותר לבדוק Web Application Penetration Testing באתר ציבורי?

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

מה עושים כאשר חלק מהנתונים חסרים?

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

כמה זמן צריך לשמור את הראיות?

הזמן תלוי במדיניות, רגולציה, עלות וסוג האירוע. חשוב להגדיר מראש Retention, Legal hold ויכולת לייצא ראיה בפורמט שניתן לאמת.

איך מתרגלים בלי לסכן מערכת אמיתית?

משתמשים במכונות וירטואליות, נתונים מדומים, CTF או מעבדה ייעודית. בבדיקות מורשות מגדירים Scope, Stop conditions וגיבוי לפני תחילת העבודה.

מקורות

רוצים לבדוק אם המסלול מתאים לכם?

השאירו פרטים ונציג של HPI יחזור אליכם לשיחת התאמה קצרה וללא התחייבות.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI

רוצים לשמוע פרטים על התוכנית? השאירו פרטים ונחזור אליכם.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI יצירת קשר

על הכותב

תאיר מלכא

מייסד ומנכ״ל HPI ומרצה לסייבר

תאיר מלכא הוא מייסד ומנכ״ל HPI – המכללה למקצועות ההייטק, ומרצה לסייבר במסלולי ההכשרה של המכללה. במסגרת תפקידיו הוא אחראי על בניית תוכניות הלימוד המקצועיות של HPI בתחומי סייבר, IT ורשתות, ומוביל את הליווי המקצועי של הסטודנטים לאורך המסלול.

לפרופיל הכותב ↗

הקודם באשכול

כתיבת דוח Penetration Test שמוביל לתיקון

הבא באשכול

OWASP Top 10:2025 — מדריך לבודקי חדירות