ניצול Web ו-Service Workers - כשתוקף משתיל נוכחות שנשארת גם אחרי התיקון¶
רוב הדיון על XSS מתמקד ברגע התקיפה עצמו - מה קורה ברגע שהקוד הזדוני רץ. אבל יש קטגוריה של תקיפות שבה הרגע המעניין באמת מגיע אחרי, כשה-XSS כבר תוקן וכולם חושבים שהסיפור נגמר. Service Workers הם בדיוק הכלי שמאפשר לתוקף להפוך פגיעה חד-פעמית לנוכחות מתמשכת בדפדפן של הקורבן, וזו בדיוק הסיבה שכל בודק חדירה רציני צריך להכיר אותם.
מה זה בעצם Service Worker¶
Service Worker הוא סקריפט שרץ ברקע בדפדפן, בנפרד מהדף עצמו, ויכול ליירט כל בקשת רשת שהדף שולח, לשנות תגובות, לשמור תוכן במטמון משלו, ואפילו לפעול כשהטאב שממנו הוא נרשם כבר סגור. הוא נועד בעיקר לבנות אפליקציות ווב שעובדות אופליין ומגיבות מהר, על ידי כך שהוא "יושב" בין הדפדפן לרשת ומחליט בעצמו אם להביא תוכן מהרשת או מהמטמון המקומי.
היכולת הזו שימושית מאוד למטרות לגיטימיות, אבל אותה יכולת בדיוק - ליירט ולשנות כל תקשורת רשת של המשתמש עם האתר - הופכת אותה למכשיר תקיפה חזק במיוחד אם תוקף מצליח לרשום Service Worker משלו.
איך תוקף בכלל מגיע לרשום Service Worker¶
הדרך הנפוצה ביותר היא דרך XSS מאוחסן. אם תוקף מצליח להזריק קוד JavaScript שמתבצע פעם אחת בלבד, אבל אותו קוד רושם Service Worker חדש עם navigator.serviceWorker.register, הוא בעצם משתיל נוכחות שממשיכה לפעול גם אחרי שהקוד המקורי שהזריק אותה כבר נעלם מהדף. גם אם צוות האבטחה מוצא ומתקן את חולשת ה-XSS המקורית, ה-Service Worker שכבר נרשם בדפדפן של הקורבן ממשיך לרוץ, כי הוא לא תלוי בקיום החולשה, אלא רק בהרשמה החד-פעמית שכבר קרתה.
// דוגמה עקרונית לרישום זדוני, לצורך הבנה בלבד
navigator.serviceWorker.register("/legit-looking-path/sw.js");
מרגע ההרשמה, הקובץ הזה שולט על כל בקשות הרשת שיוצאות מהדומיין הזה, בלי קשר לדף הספציפי שבו הקורבן נמצא.
מה בדיוק Service Worker זדוני יכול לעשות¶
- יירוט תגובות - Service Worker יכול לתפוס כל תגובה שחוזרת מהשרת ולשנות אותה לפני שהיא מגיעה לדף, כמו הזרקת קוד נוסף לכל תגובת HTML שעוברת דרכו.
- מטמון מורעל - הוא יכול לשמור גרסאות מזויפות של קבצים חשובים במטמון שלו, ולהגיש אותן לכל בקשה עתידית, גם כשהשרת האמיתי מחזיר תוכן תקין לגמרי.
- אקספילטרציה שקטה לאורך זמן - כל בקשה שיוצאת מהאתר עוברת דרכו, כך שהוא יכול לשלוח עותק של מידע רגיש לשרת של התוקף בלי שהמשתמש ירגיש בכלל שמשהו קורה.
- פעילות גם בלי טאב פתוח - בזכות יכולות כמו background sync, ה-Service Worker יכול להתעורר ולפעול גם כשהמשתמש לא נמצא בכלל באתר באותו רגע.
הגבלת ה-scope כמנגנון הגנה טבעי¶
הדבר החשוב להבין הוא שדפדפנים מגבילים Service Worker ל-scope מסוים - ברירת המחדל היא הנתיב שבו קובץ ה-Service Worker עצמו יושב ומטה, ולא כל האתר. זה אומר שתוקף שמצליח להעלות או להריץ קוד רק בנתיב מסוים לא יכול אוטומטית להשתלט על הדומיין כולו, אלא אם כן השרת מגדיר במפורש כותרת Service-Worker-Allowed שמרחיבה את ה-scope. עם זאת, ברגע שקוד רץ בנתיב עם הרשאות רחבות, או שהאתר משתמש בנתיב שורש לקבצי ה-Service Worker שלו, ה-scope הפוטנציאלי יכול להיות כל הדומיין.
איך מגנים על אפליקציה מפני זה¶
- הגבלת worker-src ב-CSP - מדיניות CSP שכוללת
worker-srcמוגדר במפורש מונעת רישום Service Workers ממקורות או נתיבים לא מורשים, גם אם תוקף מצליח להריץ קוד רגעי בדף. - שימוש זהיר ב-Service-Worker-Allowed - לא להרחיב את ה-scope של Service Worker מעבר לנדרש בפועל, כדי שגם אם קוד זדוני רץ בנתיב מסוים, הוא לא יכול להשתלט על כל הדומיין.
- ניטור רישומים חריגים - מומלץ לבדוק מדי פעם, כחלק מתהליך אבטחה שוטף, אילו Service Workers רשומים בפועל אצל משתמשים, ולזהות רישומים שלא נוצרו על ידי קוד האפליקציה הלגיטימי.
- תיקון XSS לא מספיק לבד - חשוב לזכור שתיקון חולשת ה-XSS המקורית לא מנקה Service Worker שכבר נרשם אצל משתמשים שביקרו באתר לפני התיקון. יש צורך בתהליך נפרד לזיהוי ולביטול רישום כזה.
היכולת להבין איפה תקיפה חד-פעמית הופכת לנוכחות מתמשכת היא בדיוק סוג החשיבה שמייחד בודק חדירה מנוסה. אנחנו מפתחים את החשיבה הזו לעומק בקורס פריצת אתרים מתקדמת, כי הבנת ה-Service Worker היא חלק בלתי נפרד מהבנת האפליקציה המודרנית לכל עומקה.
יש לכם שאלה על Service Workers או על תרחיש תקיפה שנתקלתם בו? מוזמנים לפתוח דיון בדיסקורד.
לסיכום¶
Service Worker זדוני שמצליח להירשם, גם דרך XSS זמני וחד-פעמי, יכול להפוך לנקודת יירוט מתמשכת שממשיכה לפעול הרבה אחרי שהחולשה המקורית תוקנה. הגנה אמיתית דורשת הגבלת worker-src ב-CSP, שימוש זהיר ב-scope, וניטור שוטף אחרי רישומים חריגים - ולא רק תיקון החולשה שאיפשרה את הרישום מלכתחילה.