אם עסקתם קצת באבטחת אתרים, בטח שמעתם על OWASP Top 10. זה הדבר הכי קרוב שיש לתעשייה שלנו לאוצר מילים משותף לגבי מה שבאמת פורץ לאתרים. הרשימה, המתעדכנת מדי פעם על ידי Open Web Application Security Project, מדרגת את הפגיעויות הנפוצות והמזיקות ביותר שנמצאות באפליקציות אמיתיות, על בסיס מידע מאלפי ארגונים.
להכיר את הרשימה זה דבר אחד. לעשות משהו בנידון זה דבר אחר. כאן נכנסת לתמונה חומת אש לאפליקציות ווב. הבה נעבור על כל אחת מהקטגוריות המרכזיות של OWASP ונראה איך חומת אש לאפליקציות ווב עוזרת בפועל, ואיפה היא לא מספיקה.
מה OWASP Top 10 באמת מודדת
OWASP Top 10 אינה רשימת בדיקה שמישהו חשב עליה בפגישה. היא נבנית מנתוני פגיעויות אמיתיים, שנתרמים על ידי חברות אבטחה, תוכניות bug bounty, וכלי בדיקת אפליקציות. כל כמה שנים הרשימה משתנה בהתאם למה שבאמת מנוצל בשטח.
הקטגוריות הנוכחיות מכילות דברים כמו בקרת גישה שבורה, כשלים קריפטוגרפיים, פגמי הזרקה (injection), תכנון לא מאובטח, ותצורה שגויה מבחינת אבטחה. חלק מהבעיות האלה הן בעיות בקוד שרק מפתח יכול לפתור. אחרות הן בדיוק הסוג של דברים שחומת אש לאפליקציות ווב נבנתה לתפוס בקצה הרשת, לפני שבקשה זדונית מגיעה בכלל לאפליקציה שלכם.
התקפות הזרקה: SQL Injection ו-Command Injection
פגמי הזרקה קורים כאשר מידע לא מהימן מוכנס לשאילתה או לפקודה בלי טיפול נכון. ניסיון קלאסי של SQL injection יכול להיראות כמו הוספת ' OR '1'='1 לשדה התחברות, בתקווה לעקוף את האימות כליל.
חומת אש לאפליקציות ווב בוחנת בקשות נכנסות ומחפשת תבניות תקיפה מוכרות כאלה. היא מזהה תווים חשודים, שאילתות פגומות, ותחביר פקודות שאין לו מה לעשות בשדה טופס. כשהיא מזהה כזה דבר, היא חוסמת את הבקשה לפני שהיא מגיעה לשכבת מסד הנתונים.
זה לא מחליף שאילתות מפורמטות (parameterized queries) בקוד שלכם. אבל זה מוסיף קו הגנה שני לפגיעויות שהמפתחים שלכם עדיין לא מצאו, או לתוסף צד שלישי שאף אחד לא בדק כבר שנתיים.
בקרת גישה שבורה (Broken Access Control)
הקטגוריה הזו מכילה מקרים שבהם משתמשים מצליחים לגשת למידע או לתפקוד שהם לא צריכים לגשת אליו. חשבו על מישהו שמשנה פרמטר בכתובת ה-URL כדי לראות חשבונית של לקוח אחר, או שעוקף בדיקות הרשאה כדי להגיע לפאנל ניהול.
לחומת אש לאפליקציות ווב יש מגבלות כאן. היא יכולה להחיל הגבלת קצב (rate limiting) ולחסום ניסיונות ברורים של מעבר בין תיקיות, ובחלק מההגדרות אפשר להגביל גישה לכתובות רגישות לפי IP או מיקום גיאוגרפי. אבל הלוגיקה של בקרת הגישה חייה בסופו של דבר באפליקציה שלכם. זה תחום שבו חומת האש תומכת בהגנות שלכם ולא מחליפה אותן.
איפה חוקים משלימים את החסר
סינון מבוסס חוקים יכול לתפוס ניסיונות להגיע לנתיבי ניהול מוכרים, לחסום גישה ישירה לקבצי תצורה, ולסמן תבניות בקשה חריגות כמו IP בודד שפוגע במאות נקודות קצה שונות של חשבונות בדקה אחת. תבנית ההתנהגות הזו לרוב מספיקה בעצמה כדי לעצור credential stuffing לפני שהוא גורם נזק.
כשלים קריפטוגרפיים
זה עוסק בעיקר במה שקורה לפני שבקשה מגיעה בכלל לחומת האש שלכם. תצורות TLS חלשות, תעודות שפג תוקפן, ומידע לא מוצפן בזמן שידור, כל אלה נמצאים מעבר למה שחומת אש לאפליקציות ווב בוחנת.
עם זאת, אירוח נכון מטפל בשכבה הזו בנפרד. חידוש אוטומטי של תעודות ותצורות TLS מודרניות סוגרים את רוב הפרצות כאן, כך שחומת האש יכולה להתמקד במה שקורה אחרי שהחיבור מאובטח. אם אתם רוצים להבין איך ניהול תעודות עובד בפועל, כתבנו על זה בפירוט רב יותר בסקירת SSL שלנו.
Cross-Site Scripting (XSS)
התקפות XSS מזריקות סקריפטים זדוניים לעמודים שנראים על ידי משתמשים אחרים, לרוב באמצעות שדות תגובה, תיבות חיפוש, או פרמטרים בכתובת URL. הסקריפט רץ בדפדפן של הקורבן ויכול לגנוב עוגיות session או להפנות משתמשים לעמודי phishing.
חומת אש לאפליקציות ווב חזקה מאוד בתחום הזה. היא סורקת תוכן נכנס ולפעמים גם יוצא, ומחפשת תגי script, מטענים מקודדים, וחתימות XSS מוכרות. מכיוון שהתבניות האלה מתועדות היטב, שיעורי הזיהוי נוטים להיות גבוהים, וההתראות השגויות ניתנות לניהול כשהחוקים מכוונים כראוי.
תצורה שגויה מבחינת אבטחה
סיסמאות מנהל כברירת מחדל, נקודות קצה לניפוי באגים שנחשפות, רשימת תיקיות שנשארה פעילה. אלה טעויות נפוצות ופשוטות לניצול כשהן מתגלות. חומת אש לאפליקציות ווב יכולה להסתיר חלק מהתסמינים על ידי חסימת גישה לנתיבים רגישים מוכרים, אבל הפתרון האמיתי הוא לתקן את התצורה השגויה עצמה.
זו הסיבה שהגנה מרובת שכבות חשובה יותר מכל כלי בודד. כתבנו על הרעיון הזה במדוע הגנה מרובת שכבות על האתר עדיפה על כל כלי בודד, וזה נכון ישירות גם כאן. חומת האש קונה לכם זמן ומקטינה את החשיפה בזמן שהבעיה הבסיסית מתוקנת.
רכיבים פגיעים ומיושנים
תוספים, ספריות, ומסגרות עבודה מיושנים הם אחת מנקודות הכניסה הנפוצות ביותר לתוקפים, במיוחד באתרי WordPress שמריצים תוספים שהופסק לתחזק אותם. חומת אש לאפליקציות ווב יכולה לחסום חתימות ניצול מוכרות שמכוונות ל-CVE מסוימים, וזה קונה זמן יקר בין חשיפת פגיעות לבין החלת תיקון.
זה רלוונטי במיוחד אם אתם מריצים WordPress. אנחנו מתעמקים בנושא ההתחברות והתוספים במדוע נהלי אבטחה טובים ל-WordPress מתחילים מסביבת האירוח ולא מהתוספים שלכם.
Server-Side Request Forgery (SSRF)
SSRF מערים על שרת לביצוע בקשות למערכות פנימיות שהוא לא אמור להיות מסוגל להגיע אליהן, לרוב בשימוש לגישה לנקודות קצה של מטא-דאטה בענן או ל-API-ים פנימיים. מערכי חוקים מודרניים של חומת אש לאפליקציות ווב כוללים יותר ויותר זיהוי ספציפי ל-SSRF, שמחפש תבניות בקשה חשודות ליוצא וטווחי IP פנימיים חסומים בכתובות URL שסופקו על ידי משתמשים.
בנייה של חוקים שעובדים בפועל
חומת אש לאפליקציות ווב טובה בדיוק כמו מערך החוקים שלה. חוקים אגרסיביים מדי חוסמים תעבורה לגיטימית ומתסכלים משתמשים אמיתיים. חוקים סלחניים מדי מאפשרים להתקפות לחמוק. יישומים טובים משתמשים בשילוב של:
- חוקים מבוססי חתימה לתבניות תקיפה מוכרות
- ניתוח התנהגותי לתפיסת חריגות שחתימות מפספסות
- מערכי חוקים שמתעדכנים באופן שוטף ועוקבים אחרי CVE-ים חדשים
- חוקים מותאמים אישית לאפליקציה הספציפית שלכם
כתבנו על המכניקה של זה בהרחבה בחוקי WAF מוסברים: איך חומת האש לאפליקציות ווב שלכם מחליטה מה לחסום, אם תרצו להתעמק יותר בלוגיקת החוקים עצמה.
מה עולה מכל זה
OWASP Top 10 היא מפה של מה שתוקפים באמת עושים, לא תרגיל תיאורטי. חומת אש לאפליקציות ווב מכסה חלק משמעותי מהמפה הזו, בפרט התקפות הזרקה, XSS, וחתימות ניצול מוכרות. היא חלשה יותר נגד פגמי לוגיקה כמו בקרת גישה שבורה, שדורשים תיקון בקוד האפליקציה שלכם.
אם אתם בוחנים אפשרויות אירוח, שאלו במפורש אם חומת אש לאפליקציות ווב כלולה ומתוחזקת באופן פעיל, ולא רק הותקנה פעם אחת ונשארה בלי טיפול. אירוח מנוהל שמקפיד לשמור על מערכי חוקים עדכניים, כולל שלנו, מוריד את הנטל הזה מכם לחלוטין כך שלא אתם צריכים לעקוב אחרי CVE-ים חדשים כל שבוע. אתם יכולים לראות איך זה משתלב בתוך הקמת אבטחת שרתים רחבה יותר בעמוד סקירת WAF שלנו.
המסר האמיתי: התייחסו ל-OWASP Top 10 כאל קו הבסיס שלכם, לא כתקרה. חומת אש טובה מטפלת בתבניות התקיפה החזרתיות והמוכרות, כך שהצוות שלכם יכול להתמקד בבעיות הקשות יותר שנמצאות בקוד שלכם.
