Cross-site scripting, המוכר יותר בשם XSS, נמצא ברשימת האיומים המובילים של OWASP כבר יותר משני עשורים. זה לא חדש וזה לא אקזוטי. ודווקא בגלל זה הוא עדיין כל כך מסוכן. תוקפים ממשיכים להשתמש בו כי הוא ממשיך לעבוד, במיוחד באתרים שמקבלים קלט מהמשתמש איפשהו, כלומר כמעט בכל אתר.
בואו נפרק מה בעצם קורה במהלך התקפת XSS, למה קשה יותר לתקן את זה לגמרי בקוד ממה שרוב האנשים חושבים, ואיך חומת אש לאפליקציות ווב תופסת את מה שהלוגיקה של האפליקציה שלכם מפספסת.
מה זה בעצם Cross-Site Scripting
XSS קורה כאשר תוקף מצליח להזריק קוד JavaScript זדוני לתוך דף שמשתמשים אחרים טוענים אחר כך בדפדפן שלהם. הסקריפט רץ באותה רמת אמון כמו הקוד הלגיטימי של האתר שלכם. זה אומר שהוא יכול לקרוא עוגיות, לגנוב טוקנים של סשן, להפנות משתמשים לדפי פישינג, או לתעד בשקט כל הקשה שמישהו מקליד בטופס.
הבעיה המרכזית פשוטה: האפליקציה שלכם מקבלת קלט ממקום כלשהו (שדה תגובות, תיבת חיפוש, פרמטר ב-URL) ומציגה אותו בחזרה בלי לנקות אותו כראוי קודם. אם הקלט הזה מכיל תג script, והקוד שלכם מציג אותו כ-HTML במקום כטקסט רגיל, הדפדפן פשוט מריץ אותו.
שלושת הסוגים העיקריים של XSS
- XSS מאוחסן (Stored XSS): הסקריפט הזדוני נשמר במסד הנתונים שלכם, לרוב דרך שדה תגובה, ביקורת או פרופיל, ורץ בכל פעם שמבקר כלשהו טוען את הדף. זה הסוג המזיק ביותר כי הוא פוגע בכולם, לא רק במי שלחץ על קישור רע.
- XSS משתקף (Reflected XSS): הסקריפט חי בתוך הבקשה עצמה, בדרך כלל בפרמטר URL, ומשתקף בחזרה בתגובה. תוקפים מסתמכים על שכנוע קורבן בודד ללחוץ על קישור מיוחד שהם יצרו.
- XSS מבוסס DOM: הפגיעות קיימת כולה בצד הלקוח, בקוד ה-JavaScript. השרת אף פעם לא רואה את המטען הזדוני כי הסקריפט של הדפדפן עצמו משנה את הדף בצורה לא בטוחה.
למה תיקון בקוד קשה יותר ממה שזה נשמע
למפתחים אומרים "פשוט תנקו את הקלט" ו"תעשו escape לפלט", וזו עצה נכונה. אבל בפועל, לאפליקציות גדולות יש מאות נקודות קלט: שדות טופס, נקודות קצה של API, העלאות קבצים, כותרות HTTP, עוגיות. פספוס של אפילו אחת יוצר פרצה. תוסיפו לזה תוספים של צד שלישי, טפסי יצירת קשר, ומערכות תגובות שלא נכתבו מתוך מחשבה על אבטחה, ותקבלו שטח פעולה גדול מאוד לכיסוי.
זה נכון במיוחד לגבי אתרי WordPress, שבהם תוספים מיוצרים שונים נוגעים כולם באותו מסד נתונים ותבניות דף. תוסף מיושן אחד עם באג בניקוי קלט יכול לחשוף את כל האתר, גם אם קוד התבנית שלכם עצמו נקי לחלוטין.
איך חומת אש לאפליקציות ווב עוצרת XSS לפני שהוא רץ
חומת אש לאפליקציות ווב יושבת בין הבקשות הנכנסות לאפליקציה שלכם, ובודקת את התוכן בפועל של כל בקשה לפני שהיא בכלל מגיעה לקוד שלכם. היא מחפשת את הדפוסים שמופיעים כמעט בכל ניסיון XSS, כמו תגי script, תכונות של event handler, או מטענים מקודדים שנועדו לעקוף מסננים חלשים.
הנה החלק הכי חשוב: חומת אש לאפליקציות ווב לא צריכה לדעת כלום על הלוגיקה הספציפית של האפליקציה שלכם כדי לתפוס את הדפוסים האלה. היא פועלת לפי חתימות תקיפה ידועות וכללים התנהגותיים, מה שאומר שהיא מגנה עליכם גם מפני פגיעויות שאתם עדיין לא יודעים שקיימות בקוד שלכם או בתוסף שהתקנתם בחודש שעבר.
זה חשוב כי תיקון כל פרצה באפליקציה לוקח זמן. מפתחים צריכים לבדוק תיקונים, לפרוס אותם, ולוודא שכלום לא נשבר. חומת אש לאפליקציות ווב קונה לכם את הזמן הזה על ידי חסימת ניסיונות ניצול בזמן שהתיקון האמיתי נבנה. אנחנו מכסים את הלוגיקה של הכללים ביתר פירוט בהסבר על כללי WAF.
איך נראה סינון XSS טוב
- חסימת בקשות המכילות תגי script גולמיים או event handlers חשודים ב-JavaScript בשדות בלתי צפויים
- תפיסת מטענים מקודדים או מוסתרים שמנסים לחמוק מהתאמת מילות מפתח פשוטה
- יישום כללים באופן עקבי בכל נקודת כניסה, לא רק בטופס ההתחברות המובן מאליו
- תיעוד ניסיונות חסומים כדי שתוכלו לראות מה באמת מנסים לזרוק על האתר שלכם
Content Security Policy: שכבה שנייה, לא תחליף
אם אתם רציניים לגבי מניעת XSS, כדאי להגדיר כותרת Content Security Policy לצד חומת האש שלכם. CSP אומרת לדפדפן בדיוק אילו מקורות סקריפטים מותר להריץ בדף שלכם, כך שגם אם תוקף מצליח להבריח סקריפט לתוך ה-HTML שלכם, הדפדפן מסרב להריץ אותו אלא אם הוא מגיע ממקור מאושר.
תחשבו על זה כהגנה מרובדת. חומת האש לאפליקציות ווב עוצרת את רוב הבקשות הזדוניות עוד לפני שהן מגיעות לשרת שלכם. CSP משמשת כרשת ביטחון בתוך הדפדפן עצמו, למקרה שמשהו מצליח לחמוק. אף אחת מהשתיים לבד היא לא פתרון שלם, אבל יחד הן מכסות את שני קצוות מעגל חיי הבקשה.
מה זה אומר עבור הגדרות האחסון שלכם
אם השרת הנוכחי שלכם לא מציע שום סינון בקשות, ההגנה מפני XSS נופלת כולה על צוות הפיתוח שלכם, שצריך לדייק בכל שורת טיפול בקלט, לתמיד, בכל תוסף ואינטגרציה שאתם מוסיפים. זה נטל כבד לצוות קטן או לבעל אתר עצמאי.
חומת אש לאפליקציות ווב מנוהלת מטפלת ברוב זה באופן אוטומטי, ומסננת בקשות זדוניות לפני שהן מגיעות לאפליקציה שלכם. למדו עוד על איך סינון בקשות עובד, ואם אתם רוצים מבט רחב יותר על המקום של XSS בין איומים נפוצים אחרים, בדקו את 10 האיומים המובילים של OWASP וכיצד חומת אש לאפליקציות ווב מטפלת בכל אחד מהם. למבט מעמיק יותר על צד ההזרקה, הפוסט שלנו על איך חומת אש לאפליקציות ווב עוצרת הזרקת SQL מכסה דפוס תקיפה קרוב מאוד.
המסקנה
XSS שורד כי קל לטעות באימות קלט וקל לפספס אותו, במיוחד ככל שהאתר שלכם גדל ומוסיפים לו עוד חלקים נעים. אתם לא יכולים לסמוך על כתיבת קוד מושלם לנצח. חומת אש לאפליקציות ווב נותנת לכם שכבה עקבית ופעילה תמיד שתופסת סקריפטים זדוניים לפני שהם בכלל נוגעים בדפדפן, וקונה לצוות שלכם את הזמן לתקן פגיעויות כראוי במקום להתחרות מול ניצול פעיל.
