מדוע צריך להגן על אפליקציות בארגונים באמצעות FIREWALL אפליקטיבי (WAF) ?

ההגנה על האפליקציות בארגונים השונים לא זכתה להיות מטופלת ע"י מנהלי אבטחת המידע עד השנים האחרונות. הסיבה לכך נעוצה במספר גורמים עיקריים :
ההגנה על האפליקציות בארגונים השונים לא זכתה להיות מטופלת ע"י מנהלי אבטחת המידע עד השנים האחרונות. הסיבה לכך נעוצה במספר גורמים עיקריים :
1.      תפיסת האבטחה והסיכונים לארגון באותם השנים שהתמקדה בעיקרה בהפרדת רשת הארגון מרשתות אחרות ומהאינטרנט תוך שימוש באמצעים תשתיתיים כגון Firewall ומערכות IDS/IPS.
תפיסה שמרנית זו אף הובילה לכך שרוב מנהלי האבטחה בארגונים הגיעו
מ-"עולם התשתיות" ולא מ-"עולם הפיתוח" פעולה שהשפיעה אף היא על החדירה האיטית של הטיפול באפליקציות בהיבטי אבטחה.
2.      העדר מודעות לתהליכי פיתוח מאובטח בעבר, הובילו ארגונים רבים להחזיק אפליקציות ללא תיעוד וללא שליטה על קוד המערכת כתוצאה מעזיבת התוכניתן הראשי, או כאשר מדובר במוצרי מדף.
אפליקציות מסוג יצרו הרתעה בקרב מנהלי האבטחה והתשתיות מלנסות ולהתמודד עם אבטחתן.
לפיכך, במהלך השנים סבלה ההגנה על השכבה האפליקטיבית מהזנחה והפכה להיות "הבטן הרכה" של כל המערכות.
ההאקרים, בזכות סביבת הניסוי ושיתוף הידע הפתוחה והיעילה שסופקה להם (האינטרנט), הבינו זאת והפנימו מהר את העובדה שעולם התשתיות מקבל טיפול שוטף ומתמיד ולכן נעשה יותר ויותר קשה לחדור דרכו. כפועל יוצא מכך הסיטו ההאקרים את מירב מאמציהם בשנים האחרונות למתקפות המתרכזות בשכבה האפליקטיבית.
המתקפות האפליקטיביות בשנים האחרונות מתמקדות בחשיפת מידע, ביצוע שינויים ו/או מחיקת מידע ישירות מבסיס הנתונים. מתקפות אלו מתבצעות באמצעות קישור האפליקציה לבסיס הנתונים, או באמצעות גניבת זהות דיגיטאלית של משתמשים אחרים, עקיפת מנגנון ההזדהות של האפליקציה, קבלת הרשאות מעבר להרשאות המורשות במערכת, ויכולות אף לכלול העלמת ראיות, פתיחת BackDoors, ופגיעה בזמינות המערכת ובאמינות האתר הגוררת פגיעה חמורה בתדמית החברה העומדת מאחורי האתר.
 
מדוע אפליקציות WEB חשופות לפרצות אבטחתיות?
אפליקציות WEB מהוות תווך בין הלקוח (Client) לשרת בסיס הנתונים. בדרך כלל מוגדר חשבון אחד עבור האפליקציה, אשר ניגש לבסיס הנתונים עם הרשאות גבוהות במערכת (SysAdmin), וכפועל יוצא מכך כל ההגבלות מבוססות על אפליקציית ה – WEB. איתור פרצה באתר WEB עלול לגרור גישה מלאה לבסיס הנתונים ואף לאפשר השתלטות על השרתים עד לרמת מערכת ההפעלה.
קיימות מתקפות רבות על אפליקציות WEB, כדוגמת: SQL Injection , XSS (Cross Site Scripting) , Session Hijacking, Parameter Tampering, DoS (Denial of Service)אפליקטיבי, Buffer Overflows, Phishing וכיוצב'.
להלן פגיעויות נפוצות אשר מתגלות באפליקציות WEB והניתנות לניצול במתפקות הרשומות לעיל :
·         עקיפת מנגנון ההזדהות ע"י שימוש בפרטי הזדהות של משתמש אחר או משתמש שאינו מורשה.
·         ביצוע בדיקות קלטים בצד ה – Client, אשר ניתן לעקוף אותם באמצעות Proxy פשוט, וכנגזרת מכן ביצוע מניפולציה על פרמטרים המועברים לשרת.
·         קיום שדות פתוחים להזנה ללא מגבלות תבנית, ערכים או אורך.
·         יכולת הגעה לאזורי URL אסורים, וכתוצאה מכך הגעה למסכים עוקפי הרשאות.
·         אי קיום מנגנון לטיפול בשגיאות, אשר מספק מידע מפורט אודות האתר, כגון סוג שרת, Port, ועוד.
·         ניהולי Session לקוי, כדוגמת אי ניתוקו אשר עלול לגרור השתלטות על ה – Session.
·         חוסר במנגנון חיוויים (Audit) אשר יכול לעזור באיתור גורמים אשר חדרו למערכת ללא הרשאה.
 
מדוע צריך להגן על אפליקציות בארגונים באמצעות FIREWALL אפליקטיבי (WAF) ?
ההתמודדות עם בעיות אפליקטיביות לא תמיד ניתנת לפתרון ברמת הקוד מהטעמים הבאים:
1.       כאשר מדובר במוצר מדף.
2.       כאשר אין עותק של הקוד במצב פתוח (לפני הידור).
3.       כלל פי 10 : כאשר תיקון ברמת הקוד עשוי לצרוך משאבים אדירים הן בכדי להכיר את הקוד ואת המקטעים הדורשים תיקון והן בכדי לבצע את פעולות השכתוב.
 
לצורך יצירת מענה אבטחתי בר ביצוע ניתן להטמיע מערכת WAF כחיץ בין האפליקציה (השרת) לדפדפן (הלקוח). מוצרי WAF נועדו להתמודד עם הפרצות האפליקטיביות שצווינו לעיל ולספק מענה לרוב הפרצות האבטחתיות הקיימות במערכות מסוג WEB. המוצרים כוללים מנגנון לזיהוי התקפות על האפליקציות המובסס על למידת האפליקציה ועל חתימות. חתימות אלו מבוססות על מחקרים שהחברות שפיתחו את המוצר מבצעות. המוצרים תומכים בעדכונים של החתימות לצורך הגנה על התקפות חדשות שההאקרים/תוקפים פוטנציאלים מבצעים על המערכות בארגון. מעבר למנגנונים האוטומטים ניתן להגדיר במוצרים מסוג זה הגדרות/הגבלות אפליקטיביות בצורה ידנית ברמת כל שדה וכל כתובת URL.
 
כיצד להטמיע את ה- WAF בצורה נכונה?
על מנת "לנצל" את המוצר בצורה אופטימאלית, יש צורך בניהול המוצר והתאמתו לארגון ולאפליקציות שעליהם הוא נועד להגן. לצורך כך מומלץ להתייחס להיבטים הבאים:
·         מנהל הWAF: על מנהל המערכת (WAF) להכיר היטב את המוצר ואת האפשרויות והתכונות שהמוצר מכיל בתוכו. בנוסף, מנהל המערכת נדרש להבין אבטחת מידע ואיומים אפליקטיביים ברמה גבוהה.
כמו כן, על מנהל המערכת להבין בפיתוח אפליקציות ובכתיבת ביטויים רגולאריים.
·         תהליכי הפיתוח : על הארגון לבצע שינויים בנהלי הפיתוח, כך שתהיה תקשורת מלאה בין צוותי הפיתוח לבין מנהל ה-WAF. כל שינוי באפליקציה חייב לבוא לידי ביטוי בהתאמות בWAF.
לדוגמה: הוספת דפים חדשים, הגדרת שדות מתאימים (כגון Integer, String), ועוד.
·         טרום עלייה לייצור : על הארגון לבצע תיאומים בין זמני ביצוע Penetration Test לבין זמן הלמידה של ה- WAF. יש לזכור כי חלק מהמוצרים מבוססים על מנוע סטטיסטי אשר לומד אלו תווים הינם תווים תקינים עבור הקלטים במערכת. חשוב להבין שמהלך ה- Penetration Test מבצעי הבדיקה מזינים תווים מסוכנים (בהיבט אבטחתי) , תווים שאסור שה- WAF ילמד אותם כתווים תקינים.
 
לסיכום :
המסקנה ממה שהוצג כאן הינה שאכן WAF הינו פתרון מצוין המאפשר הגנה על מערכות ה- WEB בארגון.
יחד עם זאת, לצורך הגעה למצב הגנה אופטימאלי יש צורך באנשי מקצוע מיומנים שעונים על כל הקריטריונים שצוינו לעיל וזאת בנוסף להירתמות הארגון בהטמעת המערכת בצורה הטובה ביותר בארגון. 

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

דילוג לתוכן