יסודות עקיפת WAF - למה חומת אש לאפליקציות היא לא קסם¶
כמעט כל אתר גדול שתפגשו היום יושב מאחורי WAF, חומת אש לאפליקציות ווב. זה נשמע כמו שכבת הגנה בלתי חדירה, וחברות רבות מתייחסות אליו בדיוק ככה - "יש לנו WAF, אז אנחנו מוגנים". הבעיה היא שההנחה הזאת שגויה, ומי שעובד באבטחת מידע ברצינות יודע שהמשפט הכי מסוכן בתחום הוא "יש לנו כלי שפותר את זה בשבילנו".
אז מה בעצם עושה WAF¶
ה-WAF יושב בין הגולשים לאתר עצמו, ובודק כל בקשה שעוברת דרכו. הוא מחפש דפוסים שמזכירים התקפות ידועות - מחרוזת שנראית כמו הזרקת SQL, תג script שמעיד על XSS, נתיב שמנסה לגשת לקבצי מערכת. אם הוא מזהה דפוס חשוד, הוא חוסם את הבקשה לפני שהיא בכלל מגיעה לשרת האפליקציה.
זה שימושי מאוד כשכבת הגנה נוספת, בדיוק בגלל שהוא לא דורש לשנות שורת קוד אחת באפליקציה עצמה. אבל בדיוק העובדה הזאת - שהוא לא נוגע בקוד - היא גם המגבלה המהותית שלו.
הבעיה הבסיסית - זיהוי דפוסים לא מבין הקשר¶
רוב מנועי ה-WAF עובדים בשיטה שנקראת התאמת חתימות (signature matching). הם משווים כל בקשה נכנסת מול רשימה של דפוסים מוכרים שנחשבים מסוכנים. הבעיה היא שדפוס זה לא הבנה - ה-WAF לא "מבין" מה הבקשה עושה, הוא רק בודק אם היא נראית דומה למשהו שהוא כבר ראה.
ברגע שהתוקף משנה את הבקשה בצורה שעדיין מבצעת בדיוק את אותה פעולה, אבל לא תואמת אף דפוס ברשימה, ה-WAF פשוט לא מזהה כלום. זה כמו שומר בכניסה למועדון שמזהה רק פרצופים ספציפיים מתמונות ישנות - אם מישהו מגיע עם משקפי שמש, הוא עובר בלי בעיה, למרות שהוא בדיוק אותו אדם.
טכניקות עקיפה ברמת העיקרון¶
חשוב להבין - המטרה כאן היא להבין את עולם המושגים, לא לספק מתכון מוכן. אבל ברמת העיקרון, כמה מהדרכים שבהן חוקרי אבטחה בודקים אם WAF באמת עוצר משהו כוללות:
- קידוד לא שגרתי - Encoding Tricks. הזנת אותו תוכן בקידוד שונה, למשל URL encoding כפול או קידוד Unicode, כך שה-WAF לא מזהה את הדפוס אבל השרת בסוף מפענח את אותו תוכן ומריץ אותו כרגיל.
- ריבוי פרמטרים - Parameter Pollution. שליחת אותו שם פרמטר כמה פעמים בבקשה אחת. שרתים שונים מתייחסים לזה אחרת - חלקם לוקחים את הערך הראשון, חלקם את האחרון, וה-WAF לפעמים בודק רק אחד מהם בעוד השרת מתייחס לאחר.
- מתודות HTTP חריגות. שימוש במתודה פחות שגרתית, כמו PUT במקום POST, כדי לגרום ל-WAF שהוגדר לבדוק בעיקר בקשות רגילות לפספס את הבקשה לגמרי.
- תרגילי אותיות רישיות ורווחים. שינוי קטן במבנה של פקודה, כמו רישיות משתנות או תוספת הערות ורווחים לא שגרתיים בתוך מחרוזת, כך שהיא עדיין תקינה מבחינת השרת אבל לא תואמת את החתימה המדויקת שה-WAF מחפש.
כל אחת מהטכניקות האלה מנצלת את אותו עקרון - פער בין איך שה-WAF "קורא" את הבקשה לבין איך שהשרת בסוף באמת מפרש אותה.
למה בודקי חדירה בכלל טורחים לעקוף WAF¶
יש כאן נקודה חשובה שכדאי להבין טוב - מבדק חדירה מקצועי כמעט תמיד מתבצע כשה-WAF פעיל, ולא בלי אותו. הסיבה היא שהמטרה של המבדק היא לא "לבדוק אם החולשה קיימת בעולם וואקום", אלא לבדוק מה באמת יכול לקרות במערכת האמיתית, כפי שהיא באמת פרוסה בייצור.
אם בודק חדירה מצליח לעקוף את ה-WAF ולהגיע לחולשה שיושבת מתחתיו, זה בדיוק המידע שהעסק צריך - זה אומר שההגנה הקיימת לא באמת מונעת ניצול בפועל, גם אם היא נראית טוב בדוח. זו לא סתם תרגיל אקדמי, זו הוכחת סיכון אמיתי לעסק.
למה WAF הוא לעולם לא תחליף לתיקון האמיתי¶
הנקודה הכי חשובה בכל הפוסט הזה היא הזאת - WAF הוא שכבת הגנה נוספת, לא פתרון לחולשה עצמה. אם יש הזרקת SQL אמיתית בקוד שלכם, ה-WAF יכול לחסום כמה דרכים ידועות לנצל אותה, אבל החולשה עדיין קיימת. מישהו שימצא דרך עקיפה, ומוקדם או מאוחר תמיד יש כזאת, יגיע ישר לחולשה שמעולם לא תוקנה.
הגישה הנכונה היא הפוכה ממה שרוב הארגונים חושבים - קודם מתקנים את החולשה בקוד עצמו, ורק אז מוסיפים WAF כשכבת הגנה נוספת שתקשה על תוקפים, לא כתחליף לעבודת התיקון עצמה.
זה בדיוק סוג החשיבה שאנחנו מפתחים בקורס פריצת אתרים מתקדם - להבין לא רק איך לנצל חולשה, אלא איך להוכיח סיכון אמיתי גם כשיש שכבות הגנה שאמורות למנוע אותו.
יש לכם שאלה על WAF ואיך לבדוק אותו נכון? בואו לדסקורד.
לסיכום¶
ה-WAF הוא כלי שימושי, אבל הוא לא קסם ולא תחליף לתיקון החולשה עצמה. הוא מזהה דפוסים, לא כוונות, ומי שמבין את הפער הזה מבין גם למה ארגונים עם WAF יקר ומתקדם עדיין נפרצים כל הזמן.