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

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

למה זיהוי מוקדם משנה הכל

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

מה בודקים בכותרות ובעוגיות

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

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

דפי חסימה כטביעת אצבע

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

הבדלי התנהגות מול payload חשוד

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

הבדלי תזמון כרמז נוסף

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

כלים שמאוטמים את התהליך

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

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

רוצים לתרגל זיהוי WAF על יעדי מעבדה אמיתיים ולהשוות תוצאות עם בודקים אחרים? בואו לדבר על זה בדיסקורד.

הצטרפו לקהילה בדיסקורד

לסיכום

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