איך להטמיע Content Security Policy לפני שקוראים מדווחים על עמודים שבורים

התחילו הטמעת Content Security Policy בתצפית ובקבוצת עמודים מייצגת. מדיניות שהועתקה יכולה לגרום לדף הבית להיראות מאובטח, ובו בזמן לשבור מדיה בכתבה, מסלול תשלום או תצוגה מקדימה של עורך. המטרה היא מדיניות שמגבילה הרצה לא רצויה ומשמרת את הפונקציות שהאתר באמת מתכוון לספק.

מפרט CSP מבחין בין מדיניות נאכפת לבין Content-Security-Policy-Report-Only, שמאפשרת לדפדפן לנטר מדיניות מוצעת בלי לאכוף אותה. report-only הוא דרך ללמוד על מה המועמדת תשפיע. הוא אינו מספק את ההגנה של אותה מדיניות כשהיא נאכפת, ואינו מכבה מדיניות נפרדת שכבר נאכפת.

ממפים את האתר שמפעילים בפועל

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

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

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

מגישים את המדיניות המוצעת בכותרת report-only

המפרט קובע שמדיניות report-only אינה נתמכת בתוך רכיב meta. הגדירו את כותרת תגובת ה-HTTP באמצעות תהליך ההעלאה שהאתר תומך בו. שמרו על תמונת מצב של המדיניות הנאכפת הנוכחית: ניטור מועמדת נוספת אינו מוכיח שכל ההגבלות הקיימות הוסרו.

בחרו הסדר דיווח נתמך ואשרו שנקודת הקצה המקבלת אכן קולטת את הדוחות הצפויים. ההסבר של MDN לכותרת מפרט הגשה והגדרות דיווח. עצם כתיבת הוראת דיווח אינה יוצרת שירות שמקבל, שומר ובודק את הנתונים.

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

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

הופכים דוחות להחלטות, ולא לרשימת הרשאות מתרחבת

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

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

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

אוכפים בשינוי מבוקר וממשיכים לעקוב

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

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

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

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