בדיוק השקתם תהליך תשלום חדש. הזמנות מתחילות להיכנס, ואז פתאום נעצרות. פניות תמיכה מצטברות עם אותה תלונה: "ניסיתי לשלוח את הטופס וקיבלתי דף שגיאה". בודקים את יומני השרת ומגלים שהאשם הוא לא באג בקוד. זו חומת האש לאפליקציות ווב שלכם עצמכם שחוסמת לקוחות אמיתיים.
זו אחת החוויות המתסכלות ביותר באבטחת אתרים. הכלי שאמור להגן על האתר שלכם בסופו של דבר פוגע בהמרות שלכם במקום זאת. בואו נדבר על למה זה קורה ואיך לתקן את זה בלי לכבות את ההגנה לגמרי.
מהי בעצם תוצאה שגויה
חומת אש לאפליקציות ווב בודקת בקשות נכנסות ומשווה אותן לכללים שנועדו לזהות דפוסים זדוניים, כמו ניסיונות SQL injection, תגי script, או העלאות קבצים חשודות. תוצאה שגויה קורית כשבקשה תמימה לגמרי מסומנת כהתקפה.
גורמים נפוצים לכך כוללים:
- טפסי יצירת קשר עם שדות טקסט ארוכים שמכילים מילים כמו "select" או "union" (מילות מפתח נפוצות ב-SQL אבל גם באנגלית רגילה)
- עורכי טקסט עשיר ששולחים תוכן שדומה ל-HTML
- תיבות חיפוש שבהן משתמשים מקלידים תווים מיוחדים כמו גרשיים או סוגריים משולשים
- טפסי העלאת קבצים עם סוגי MIME או שמות קבצים מסוימים
- אינטגרציות API ששולחות מטענים בפורמט JSON שנראים חריגים לכללים גנריים
החלק המסובך הוא שאותו דפוס שנראה כמו התקפה בהקשר אחד יכול להיות לגמרי תמים בהקשר אחר. שדה תגובה בבלוג ושדה התחברות באותו אתר צריכים רמות שונות מאוד של בדיקה.
למה זה חשוב יותר ממה שחושבים
תוצאה שגויה היא לא רק מטרד. זו פגיעה ישירה בעסק שלכם. אם לקוח לא יכול להשלים תשלום, לשלוח פניית תמיכה, או להירשם לשירות שלכם, אתם מפסידים את ההמרה הזו. גרוע מכך, ייתכן שהוא בכלל לא יספר לכם למה. הוא פשוט יעזוב.
זו הסיבה שחלק מבעלי האתרים מתוסכלים ומבטלים את חומת האש לגמרי אחרי חוויה גרועה אחת. זה הצעד הלא נכון. הוא מחליף בעיה אחת בבעיה הרבה יותר גדולה. הדרך הנכונה יותר היא כוונון.
איך לאבחן תוצאה שגויה
בדקו קודם את היומנים
כל חומת אש לאפליקציות ווב סבירה מתעדת ביומן איזה כלל הפעיל את החסימה, יחד עם פרטי הבקשה. לפני שנוגעים בהגדרות כלשהן, מצאו את רשומת היומן הספציפית הזו. אתם רוצים לדעת בדיוק איזה כלל הופעל ולמה.
שחזרו את הבעיה
נסו לשחזר בעצמכם את הפעולה שנחסמה. שימו לב לקלט המדויק שגרם לחסימה. לפעמים זה דפוס ברור, כמו גרש בשדה שם משפחה. פעמים אחרות זה משהו עדין יותר, כמו ערך שדה נסתר מתוסף צד שלישי.
ודאו שזו באמת תוצאה שגויה
לפני שאתם מרפים על כלל כלשהו, ודאו שהתעבורה באמת לגיטימית. בדקו את כתובת ה-IP המבקשת, את ה-user agent, ואת התזמון. בקשה בודדת שנחסמה מלקוח אמיתי היא שונה מדפוס של בקשות חסומות ממנוע סריקה אוטומטי שבודק את הטפסים שלכם.
אסטרטגיות כוונון שלא פוגעות באבטחה
הגדירו כללים בצמצום, לא בהרחבה
הטעות הכי גדולה בכוונון היא ביטול קטגוריית כלל שלמה כדי לתקן טופס אחד. אם כלל חוסם דפוסים דמויי SQL וזה גורם לבעיות בעמוד יצירת הקשר שלכם, אל תכבו את ההגנה מפני SQL injection בכל האתר. במקום זאת, צרו חריגה שמוגבלת לנתיב ה-URL ולפרמטר הספציפיים הללו.
השתמשו ברשימות היתר לדפוסים ידועים כתקינים
אם האפליקציה שלכם שולחת באופן לגיטימי מבני HTML או JSON מסוימים, הוסיפו את הדפוס הספציפי הזה לרשימת ההיתר עבור נקודת הקצה הספציפית, במקום לפתוח את הדלת לכל דבר.
התאימו את רמת הרגישות לפי ההקשר
הרבה חומות אש מודרניות תומכות ברמות רגישות שונות של כללים לחלקים שונים באתר. אזור תגובות הבלוג הציבורי שלכם יכול לפעול עם כללים רפויים יותר מדף ההתחברות למנהל או מטופס התשלום. התייחסו לאלה כאזורי סיכון נפרדים.
בדקו במצב ניטור לפני אכיפה
הגדרות WAF טובות מאפשרות להריץ כללים חדשים או מותאמים במצב תיעוד בלבד קודם. זה מראה לכם מה היה נחסם בלי לחסום בפועל, כדי שתוכלו לבדוק דפוסי תעבורה אמיתיים לפני שאתם מפעילים אכיפה. השלב הזה לבדו מונע את רוב ההפתעות ביום ההשקה.
בדקו כללים מחדש אחרי כל שינוי גדול באתר
הוספתם תוסף חדש, שילבתם שער תשלום חדש, או עיצבתם מחדש את הטפסים שלכם? זה בדיוק הזמן לבדוק מחדש את כללי חומת האש שלכם. קוד חדש לרוב מכניס דפוסי בקשה חדשים שהכללים הקיימים שלכם עדיין לא ראו.
למה כוונון מנוהל עדיף על ניחושים
כוונון טוב של חומת אש דורש תשומת לב מתמשכת. אתם צריכים להכיר את דפוסי התעבורה הרגילים של האפליקציה שלכם, להבין אילו כללים חשובים למחסנית הטכנולוגית הספציפית שלכם, ולהתאים ככל שהאתר שלכם מתפתח. זה בדיוק סוג התחזוקה שקל להזניח כשאתם עסוקים בניהול עסק.
באחסון מנוהל, הכוונון הזה בדרך כלל מטופל על ידי אנשים שבוחנים את היומנים האלה על פני אלפי אתרים ויודעים אילו דפוסים בטוח לאפשר. אם אתם רוצים להבין את המנגנון הרחב יותר של איך מתקבלות החלטות חסימה, כתבנו על זה בהסבר על כללי WAF: איך חומת האש לאפליקציות ווב שלכם מחליטה מה לחסום. תוכלו גם לראות איך הגדרה מנוהלת משתווה לכוונון כללים בעצמכם בההשוואה שלנו בין חומת אש לאפליקציות ווב מנוהלת מול מוגדרת עצמאית.
רשימת בדיקה מעשית לצמצום תוצאות שגויות
- תעדו הכל לפני שאתם חוסמים משהו, בדקו דפוסים במשך שבוע לפחות
- הגבילו חריגות לעמודים ופרמטרים ספציפיים, לעולם אל תכבו קטגוריה שלמה
- הפרידו בין רגישות כללים לעמודים ציבוריים לעומת אזורי ניהול ותשלום
- בדקו מחדש אחרי כל שינוי משמעותי בקוד, בתוסף, או בשער תשלום
- שמרו תיעוד של כל חריגה שהוספתם ולמה, כדי ששינויים עתידיים לא יחזירו את אותה בעיה
אם אתם בוחנים איך סינון בקשות וכללים מבוססי מדינה משתלבים בתמונה הזו, הסקירה שלנו על WAF מכסה את אפשרויות הסינון הזמינות ברמת האחסון.
המסקנה
חומת אש לאפליקציות ווב שחוסמת יותר מדי בתוקפנות לא באמת מגנה על העסק שלכם, היא רק מעבירה את הנזק מתוקפים ללקוחות שלכם עצמכם. הפתרון הוא לא לכבות אותה. הוא לכוון את הכיוון בצורה מדויקת יותר. תעדו קודם, הגבילו חריגות בצמצום, והתייחסו לכל תוצאה שגויה כאל מידע על איך האפליקציה הספציפית שלכם מתנהגת. עשו את זה באופן עקבי, ותקבלו הגנה אמיתית בלי נזק אגבי.
