אפליקציות אינטרנט רבות צריכות להציג תוכן בשליטת המשתמש. התהליך הזה יכול להיות פשוט כמו הצגת תמונות שהעלו משתמשים (לדוגמה, תמונות פרופיל) או מורכב כמו עיבוד HTML בשליטת המשתמש (למשל, מדריך לפיתוח אתרים). תמיד היה קשה לעשות זאת באופן מאובטח, לכן השקענו מאמצים כדי למצוא פתרונות קלים אך מאובטחים שניתן להחיל על רוב הסוגים של אפליקציות אינטרנט.
פתרונות קלאסיים לבידוד תוכן לא מהימן
הפתרון הקלאסי להצגה מאובטחת של תוכן בשליטת המשתמשים הוא שימוש במה שמכונה דומיינים של ארגז חול. הרעיון הבסיסי הוא שאם הדומיין הראשי של האפליקציה הוא example.com, תוכלו להציג את כל התוכן הלא מהימן ב-exampleusercontent.com. מכיוון ששני הדומיינים האלה נמצאים בכמה אתרים, כל תוכן זדוני ב-exampleusercontent.com לא יכול להשפיע על example.com.
אפשר להשתמש בגישה הזו כדי להציג בצורה בטוחה את כל סוגי התוכן הלא מהימן, כולל תמונות, הורדות ו-HTML. יכול להיות שלא נראה שיש צורך להשתמש באפשרות הזו עבור תמונות או הורדות, אבל פעולה כזו עוזרת להימנע מסיכונים שנובעים מגניבת תוכן, במיוחד בדפדפנים מדור קודם.
דומיינים מסוג Sandbox נמצאים בשימוש נרחב בתחום והם פועלים היטב במשך זמן רב. אבל יש להם שני חסרונות עיקריים:
- לעיתים קרובות, אפליקציות צריכות להגביל את הגישה לתוכן של משתמש יחיד, לשם כך נדרש אימות והרשאה. דומיינים של ארגז חול לא משתפים קובצי cookie עם הדומיין הראשי של האפליקציה, ולכן קשה מאוד לעשות זאת באופן מאובטח. כדי לתמוך באימות, האתרים צריכים להסתמך על כתובות URL עם יכולות או להגדיר קובצי cookie נפרדים לאימות לדומיין של ארגז החול. השיטה השנייה הזו בעייתית במיוחד באינטרנט המודרני, שבו הרבה דפדפנים מגבילים קובצי Cookie מאתרים שונים כברירת מחדל.
- התוכן של המשתמשים מבודד מהאתר הראשי, אבל הוא לא מבודד מתוכן של משתמשים אחרים. זה עלול לגרום לכך שתוכן משתמש זדוני יתקוף נתונים אחרים בדומיין ה-Sandbox (לדוגמה, דרך קריאת נתונים מאותו מקור).
כדאי גם לציין שדומיינים של ארגז חול עוזרים לצמצם את סיכוני הפישינג, כי המשאבים מפולחים בבירור לדומיין מבודד.
פתרונות מודרניים להצגת תוכן למשתמשים
עם הזמן האינטרנט התפתח, ועכשיו יש דרכים קלות ומאובטחות יותר להציג תוכן לא מהימן. יש כאן הרבה גישות שונות, לכן נציג שני פתרונות שנמצאים כרגע בשימוש נרחב ב-Google.
גישה 1: הצגת תוכן למשתמשים לא פעילים
אם באתר מסוים צריך להציג רק תוכן של משתמשים לא פעילים (כלומר תוכן שאינו HTML או JavaScript, לדוגמה, תמונות והורדות), אפשר עכשיו לעשות זאת באופן בטוח ללא דומיין ארגז חול מבודד. יש שני שלבים עיקריים:
- צריך תמיד להגדיר את הכותרת
Content-Typeלסוג MIME ידוע, שנתמך על ידי כל הדפדפנים ומובטח שהוא לא מכיל תוכן פעיל (אם יש ספק,application/octet-streamהוא בחירה בטוחה). - בנוסף, תמיד צריך להגדיר את כותרות התגובה הבאות כדי להבטיח שהדפדפן יבודד באופן מלא את התגובה.
| כותרת התגובה | מטרה |
|---|---|
X-Content-Type-Options: nosniff |
מניעת לכידת תוכן |
Content-Disposition: attachment; filename="download" |
הוא מפעיל הורדה במקום רינדור |
Content-Security-Policy: sandbox |
התוכן נשמר בארגז חול (Sandbox), כאילו הוא הוצג בדומיין נפרד |
Content-Security-Policy: default-src ‘none' |
השבתת ההפעלה של JavaScript (והכללה של משאבי המשנה) |
Cross-Origin-Resource-Policy: same-site |
מניעת הכללה של הדף באתרים שונים |
שילוב הכותרות הזה מבטיח שהתגובה תיטען רק כמשאב משנה על ידי האפליקציה, או שהמשתמשים יוכלו להוריד אותה כקובץ. בנוסף, הכותרות מספקות כמה שכבות הגנה מפני באגים בדפדפן דרך כותרת ארגז החול של CSP וההגבלה default-src. באופן כללי, ההגדרה שפורטה למעלה מספקת מידה גבוהה של ביטחון שהתגובות שנשלחות באופן הזה לא יכולות להוביל לנקודות חולשה או להזרקות באמצעות בידוד.
הגנה לעומק
הפתרון שלמעלה מייצג הגנה מספקת באופן כללי מפני XSS, אבל יש כמה אמצעי הקשחה נוספים שאפשר להשתמש בהם כדי לספק שכבות אבטחה נוספות:
- צריך להגדיר כותרת
X-Content-Security-Policy: sandboxלתאימות ל-IE11. - מגדירים כותרת
Content-Security-Policy: frame-ancestors 'none'כדי למנוע את ההטמעה של נקודת הקצה. - תוכן של משתמשים ב-Sandbox בתת-דומיין מבודד באמצעות:
- הצגת תוכן של משתמשים בתת-דומיין מבודד (למשל, Google משתמשת בדומיינים כמו
product.usercontent.google.com). - צריך להגדיר את
Cross-Origin-Opener-Policy: same-originואתCross-Origin-Embedder-Policy: require-corpכדי להפעיל בידוד בין מקורות.
- הצגת תוכן של משתמשים בתת-דומיין מבודד (למשל, Google משתמשת בדומיינים כמו
גישה 2: הצגת תוכן פעיל של משתמשים
ניתן גם להציג באופן בטוח תוכן פעיל (לדוגמה, תמונות HTML או SVG) ללא נקודות החולשה של הגישה הקלאסית של דומיין Sandbox.
האפשרות הפשוטה ביותר היא להשתמש בכותרת Content-Security-Policy: sandbox כדי לומר לדפדפן לבודד את התשובה. נכון לעכשיו, לא כל דפדפני האינטרנט מטמיעים בידוד של תהליך עבור מסמכי ארגז חול, אבל שיפורים מתמשכים במודלים של תהליכי דפדפן צפויים לשפר את ההפרדה בין תוכן בארגז חול להטמעה של אפליקציות. אם ההתקפות של SpectreJS וסיכון של כלי עיבוד הן מחוץ למודל האיומים שלך, סביר להניח שהשימוש ב-Sandbox של CSP הוא פתרון מספיק.
ב-Google פיתחנו פתרון שיכול לבודד באופן מלא תוכן פעיל לא מהימן על ידי עדכון של המושג 'דומיינים של ארגז חול'. הרעיון המרכזי הוא:
- ליצור דומיין Sandbox חדש שיתווסף לרשימת הסיומות הציבוריות. לדוגמה, על ידי הוספה של
exampleusercontent.comל-PSL, אפשר להבטיח שה-foo.exampleusercontent.comו-bar.exampleusercontent.comנמצאים בין אתרים שונים, ולכן מבודדים זה מזה באופן מלא. - כתובות URL שתואמות ל-
*.exampleusercontent.com/shimמנותבות לקובץ shim סטטי. קובץ ה-shim הזה מכיל קטע קוד קצר של HTML ו-JavaScript שמאזינים לגורם המטפל באירועים שלmessageומעבד את התוכן שהוא מקבל. - כדי להשתמש באפשרות הזו, המוצר יוצר iframe או חלון קופץ אל
$RANDOM_VALUE.exampleusercontent.com/shimומשתמש ב-postMessageכדי לשלוח את התוכן הלא מהימן לספריית shim לצורך עיבוד. - התוכן שעבר עיבוד הופך ל-blob ומעובד ב-iframe שבארגז חול (sandbox).
בהשוואה לגישה הקלאסית של דומיין ארגז חול, כך ניתן להבטיח שכל התוכן יהיה מבודד לגמרי באתר ייחודי. בנוסף, מאחר שהאפליקציה העיקרית באחזור הנתונים לצורך עיבוד, אין יותר צורך להשתמש בכתובות URL של יכולות.
סיכום
שני הפתרונות האלה מאפשרים לעבור מדומיינים קלאסיים של ארגז חול, כמו googleusercontent.com, לפתרונות מאובטחים יותר שתואמים לחסימת קובצי cookie של צד שלישי. ב-Google כבר העברנו מוצרים רבים כדי להשתמש בפתרונות האלה, ואנחנו מתוכננות עוד העברות בשנה הבאה.