Content Security Policy (CSP) עוזר לוודא שכל התוכן שנטען בדף נחשב למהימן על ידי בעלי האתר. CSP מצמצמים מתקפות של סקריפטים חוצי-אתרים (XSS) כי הם יכולים לחסום סקריפטים לא בטוחים שהוחדרו על ידי תוקפים. עם זאת, ניתן לעקוף את ה-CSP בקלות אם היא לא מחמירה מספיק. מידע נוסף זמין במאמר צמצום סקריפטים חוצי-אתרים (XSS) בעזרת מדיניות אבטחת תוכן מחמירה (CSP). מערכת Lighthouse אוספת נתוני CSP שנאכפים במסמך הראשי, ומדווחת על בעיות מ-CSP Evaluator אם ניתן לעקוף אותן.
שיטות נדרשות ל-CSP שלא ניתן לעקוף
כדאי ליישם את השיטות הבאות כדי להבטיח שלא ניתן יהיה לעקוף את ה-CSP שלכם. אם ניתן לעקוף את ה-CSP, מערכת Lighthouse שולחת אזהרה בדרגת חומרה גבוהה.
יעדי XSS של CSP
כדי לטרגט XSS, מדיניות CSP צריכה לכלול את ההוראות script-src, object-src ו-base-uri. כמו כן, ה-CSP צריך להיות נקי משגיאות תחביר.
script-src ו-object-src מאבטחים דף מפני סקריפטים לא בטוחים ויישומי פלאגין לא בטוחים, בהתאמה. לחלופין, ניתן להשתמש ב-default-src כדי להגדיר מדיניות רחבה במקום הוראות רבות, כולל script-src ו-object-src.
base-uri מונעת החדרה של תגי <base> לא מורשים שניתן להשתמש בהם כדי להפנות את כל כתובות ה-URL היחסיות (כמו סקריפטים) לדומיין שנשלט על ידי תוקף.
ב-CSP נעשה שימוש בגיבובים (hash) או בצפנים חד-פעמיים (hash) כדי להימנע מעקף לרשימת ההיתרים
מדיניות CSP שמגדירים רשימת היתרים עבור script-src מסתמכת על ההנחה שכל התגובות שמגיעות מדומיין מהימן הן בטוחות, וניתן להפעיל אותן כסקריפטים. עם זאת, ההנחה הזו לא תקפה לאפליקציות מודרניות. חלק מהדפוסים השימושיים השכיחים, כמו חשיפת ממשקי JSONP ואירוח עותקים של ספריית AngularJS, מאפשרים לתוקפים לחמוק מגבולות ה-CSP.
בפועל, אף על פי שייתכן שלא יהיה ברור למחברי האפליקציות את רוב רשימות ההיתרים של script-src ניתן לעקוף על ידי תוקף באמצעות באג XSS, ולספק מעט הגנה מפני הזרקת סקריפטים. לעומת זאת, הגישות החדשות והמבוססות על גיבוב לא מושפעות מהבעיות האלה, והן עוזרות לאמץ מדיניות מאובטחת יותר ולשמור עליה.
לדוגמה, הקוד הזה משתמש בנקודת קצה מסוג JSONP שמתארחת בדומיין מהימן כדי להחדיר סקריפט שנשלט על ידי תוקף:
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
כדי למנוע עקיפה, מדיניות CSP צריכה לאפשר בנפרד סקריפטים המשתמשים בגיבובים (hash) או בצפנים חד-פעמיים (hash) ולהשתמש ב-'strict-Dynamic' במקום ברשימת היתרים.
המלצות נוספות למדיניות CSP מאובטחת
כדאי ליישם את השיטות הבאות כדי לשפר את האבטחה והתאימות. אם ה-CSP לא פועל בהתאם לאחת מההמלצות, תופיע אזהרה בדרגת חומרה בינונית מ-Lighthouse.
הגדרת דיווח של CSP
הגדרת יעד לדיווח תעזור לעקוב אחר תקלות. אפשר להגדיר את יעד הדיווח באמצעות ההוראות report-uri או report-to. report-to לא נתמך כרגע בכל הדפדפנים המתקדמים, ולכן מומלץ להשתמש בשניהם או רק ב-report-uri.
אם יש תוכן שמפר את ה-CSP, הדפדפן ישלח דוח ליעד שהוגדר. עליך לוודא שהגדרת אפליקציה ביעד הזה שמטפלת בדוחות האלה.
הגדרת ה-CSP בכותרת HTTP
ניתן להגדיר CSP במטא תג באופן הבא:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
עם זאת, אם אפשר, עליכם להגדיר מדיניות CSP בכותרת של תגובת HTTP. הזרקה לפני המטא תג תעקוף את ה-CSP. בנוסף, frame-ancestors, sandbox ודיווח אינם נתמכים ב-CSP של מטא תגים.
בדיקת תאימות ל-CSP לאחור
לא כל הדפדפנים תומכים בגיבובים או בצפנים חד-פעמיים של CSP, ולכן מומלץ להוסיף את unsafe-inline כחלופה לדפדפנים שלא עומדים בדרישות. אם הדפדפן תומך בגיבובים/צפנים חד-פעמיים, המערכת תתעלם מ-unsafe-inline.
באופן דומה, strict-dynamic לא נתמך בכל הדפדפנים. מומלץ להגדיר רשימת היתרים כחלופה לדפדפנים שלא עומדים בדרישות. דפדפנים שתומכים ב-strict-dynamic לא ייכללו ברשימת ההיתרים.
איך לפתח מדיניות CSP מחמירה
בהמשך מוצגת דוגמה לשימוש ב-CSP מחמיר עם מדיניות מבוססת-nonce.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
בכל פעם שהדף נטען, הערך random123 יהיה כל מחרוזת base64 שנוצרה בצד השרת. בדפדפנים מודרניים, המערכת מתעלמת מ-unsafe-inline ומ-https: בגלל החד-פעמי (nonce) ו-strict-dynamic. מידע נוסף על שימוש ב-CSP מחמיר זמין במדריך הקפדני ל-CSP.
אפשר לבדוק ב-CSP אם יש דרכים לעקיפת הבעיה באמצעות Lighthouse ו-CSP Evaluator. כדי לבדוק מדיניות CSP חדשה בלי להסתכן בפריצה של דפים קיימים, צריך להגדיר את ה-CSP במצב דוח בלבד תוך שימוש ב-Content-Security-Policy-Report-Only כשם הכותרת. הפעולה הזו תשלח הפרות של CSP לכל יעדי הדיווח שהגדרת באמצעות report-to ו-report-uri, אבל לא תיאכף בפועל את ה-CSP.