כותרות אבטחת רשת: מדיניות אבטחת תוכן והרצת JavaScript

בנוף הדיגיטלי המורכב של ימינו, אבטחת יישומי רשת היא בעלת חשיבות עליונה. אחת ההגנות היעילות ביותר נגד מגוון התקפות, במיוחד Cross-Site Scripting (XSS), היא השימוש בכותרות אבטחת רשת (Web Security Headers). בין אלה, מדיניות אבטחת תוכן (CSP) בולטת כמנגנון רב עוצמה לשליטה במשאבים שדפדפן רשאי לטעון עבור עמוד נתון. מאמר זה מספק מדריך מקיף להבנה ויישום יעיל של CSP כדי להגן על יישומי הרשת והמשתמשים שלכם.

הבנת כותרות אבטחת רשת

כותרות אבטחת רשת הן כותרות תגובת HTTP המספקות הוראות לדפדפן כיצד להתנהג בעת טיפול בסוגי תוכן מסוימים. הן מהוות חלק חיוני באסטרטגיית הגנה לעומק (defense-in-depth), הפועלות לצד אמצעי אבטחה אחרים כדי למזער סיכונים.

כמה מכותרות אבטחת הרשת הנפוצות ביותר כוללות:

• מדיניות אבטחת תוכן (CSP): שולטת במשאבים שה-user agent רשאי לטעון.
• HTTP Strict Transport Security (HSTS): מאלצת דפדפנים להשתמש ב-HTTPS.
• X-Frame-Options: מגנה מפני התקפות Clickjacking.
• X-Content-Type-Options: מונעת פגיעויות של MIME-sniffing.
• Referrer-Policy: שולטת בכמות המידע על המפנה (referrer) שיש לכלול בבקשות.
• Permissions-Policy (לשעבר Feature-Policy): מאפשרת שליטה פרטנית בתכונות הדפדפן.

מאמר זה מתמקד בעיקר במדיניות אבטחת תוכן (CSP) ובהשפעתה על הרצת JavaScript.

מהי מדיניות אבטחת תוכן (CSP)?

CSP היא כותרת תגובת HTTP המאפשרת לכם להגדיר רשימה לבנה (whitelist) של מקורות שמהם הדפדפן רשאי לטעון משאבים. זה כולל JavaScript, CSS, תמונות, גופנים ונכסים אחרים. על ידי הגדרה מפורשת של מקורות מהימנים אלה, תוכלו להפחית באופן משמעותי את הסיכון להתקפות XSS, שבהן סקריפטים זדוניים מוזרקים לאתר שלכם ומורצים בהקשר של דפדפני המשתמשים.

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

מדוע CSP חשוב להרצת JavaScript?

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

CSP יכול למנוע ביעילות התקפות אלה על ידי הגבלת המקורות שמהם ניתן לטעון ולהריץ JavaScript. כברירת מחדל, CSP חוסם את כל ה-JavaScript המוטבע (inline) (קוד בתוך תגי <script>) ו-JavaScript שנטען מדומיינים חיצוניים. לאחר מכן, אתם מאפשרים באופן סלקטיבי מקורות מהימנים באמצעות הוראות CSP.

הוראות CSP: אבני הבניין של המדיניות שלכם

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

• default-src: משמשת כברירת מחדל עבור הוראות fetch אחרות. אם הוראה ספציפית אינה מוגדרת, נעשה שימוש ב-default-src.
• script-src: מציינת את המקורות המותרים לקוד JavaScript.
• style-src: מציינת את המקורות המותרים לגליונות סגנון CSS.
• img-src: מציינת את המקורות המותרים לתמונות.
• font-src: מציינת את המקורות המותרים לגופנים.
• media-src: מציינת את המקורות המותרים לקבצי שמע ווידאו.
• object-src: מציינת את המקורות המותרים לתוספים (למשל, Flash).
• frame-src: מציינת את המקורות המותרים למסגרות (<frame>, <iframe>).
• connect-src: מציינת את המקורות המותרים לבקשות רשת (למשל, XMLHttpRequest, Fetch API, WebSockets).
• base-uri: מגבילה את כתובות ה-URL שניתן להשתמש בהן באלמנט <base> של המסמך.
• form-action: מגבילה את כתובות ה-URL שאליהן ניתן לשלוח טפסים.
• upgrade-insecure-requests: מורה לדפדפן לשדרג את כל כתובות ה-URL הלא מאובטחות (HTTP) לכתובות URL מאובטחות (HTTPS).
• block-all-mixed-content: מונעת מהדפדפן לטעון משאבים כלשהם באמצעות HTTP כאשר הדף נטען באמצעות HTTPS.

כל הוראה יכולה לקבל מגוון ביטויי מקור, כולל:

• *: מאפשרת משאבים מכל מקור (בדרך כלל לא מומלץ).
• 'self': מאפשרת משאבים מאותו מקור (סכמה, מארח ויציאה) כמו המסמך.
• 'none': אוסרת על משאבים מכל המקורות.
• 'unsafe-inline': מאפשרת שימוש ב-JavaScript ו-CSS מוטבעים (inline) (מאוד לא מומלץ).
• 'unsafe-eval': מאפשרת שימוש ב-eval() ופונקציות קשורות (מאוד לא מומלץ).
• 'unsafe-hashes': מאפשרת מטפלי אירועים מוטבעים (inline) ספציפיים על בסיס ה-hash שלהם (SHA256, SHA384, or SHA512) (יש להשתמש בזהירות).
• data:: מאפשרת data: URIs (למשל, תמונות מוטבעות המקודדות כ-base64).
• https://example.com: מאפשרת משאבים מהדומיין (ואופציונלית מהיציאה) שצוין באמצעות HTTPS.
• *.example.com: מאפשרת משאבים מכל תת-דומיין של example.com.
• nonce-{random-value}: מאפשרת סקריפטים או סגנונות מוטבעים (inline) ספציפיים בעלי תכונת nonce תואמת (מומלץ לקוד מוטבע).
• sha256-{hash-value}: מאפשרת סקריפטים או סגנונות מוטבעים (inline) ספציפיים בעלי hash SHA256 תואם (חלופה ל-nonces).

יישום CSP: דוגמאות מעשיות

ישנן שתי דרכים עיקריות ליישם CSP:

1. כותרת HTTP: שליחת כותרת Content-Security-Policy בתגובת ה-HTTP. זוהי השיטה המועדפת.
2. תג <meta>: שימוש בתג <meta> במקטע <head> של מסמך ה-HTML. לשיטה זו יש מגבלות ובדרך כלל אינה מומלצת.

שימוש בכותרת HTTP

כדי להגדיר את כותרת ה-CSP, עליכם להגדיר את תצורת שרת האינטרנט שלכם. השלבים המדויקים ישתנו בהתאם לשרת שלכם (למשל, Apache, Nginx, IIS).

הנה כמה דוגמאות לכותרות CSP:

CSP בסיסי

מדיניות זו מאפשרת משאבים רק מאותו המקור:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

אישור משאבים מדומיינים ספציפיים

מדיניות זו מאפשרת JavaScript מ-https://cdn.example.com ותמונות מ-https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

שימוש ב-Nonces עבור סקריפטים מוטבעים (Inline)

מדיניות זו מאפשרת סקריפטים מוטבעים בעלי תכונת nonce תואמת:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

ב-HTML שלכם:

            <script nonce="rAnd0mN0nc3">
 // Your inline script
</script>
            

              
                Copy
              
            
          

הערה: ערך ה-nonce צריך להיות מופק באופן אקראי עבור כל בקשה כדי למנוע מתוקפים לעקוף את ה-CSP.

שימוש ב-Hashes עבור סקריפטים מוטבעים (Inline)

מדיניות זו מאפשרת סקריפטים מוטבעים ספציפיים על בסיס ה-hash SHA256 שלהם:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

כדי ליצור את ה-hash SHA256, ניתן להשתמש במגוון כלים מקוונים או כלי שורת פקודה (למשל, openssl dgst -sha256 -binary input.js | openssl base64).

שימוש בתג <meta>

אף על פי שאינו מומלץ למדיניות מורכבת, ניתן להשתמש בתג <meta> כדי להגדיר CSP בסיסי. לדוגמה:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

מגבלות תג ה-<meta>:

• לא ניתן להשתמש בו כדי לציין את הוראת report-uri.
• אינו נתמך באופן נרחב כמו כותרת ה-HTTP.
• פחות גמיש וקשה יותר לניהול עבור מדיניות מורכבת.

מצב דיווח בלבד של CSP

לפני אכיפת CSP, מומלץ מאוד להשתמש בכותרת Content-Security-Policy-Report-Only. הדבר מאפשר לכם לנטר את השפעת המדיניות שלכם מבלי לחסום בפועל משאבים כלשהם. הדפדפן ידווח על כל הפרה לכתובת URL שצוינה, מה שמאפשר לכם לכוונן את המדיניות שלכם לפני פריסתה בסביבת הייצור (production).

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

תצטרכו להגדיר נקודת קצה בצד השרת (למשל, /csp-report) כדי לקבל ולעבד את דוחות ה-CSP. דוחות אלה הם בדרך כלל אובייקטי JSON המכילים מידע על ההוראה שהופרה, ה-URI שנחסם ופרטים רלוונטיים אחרים.

טעויות נפוצות ב-CSP וכיצד להימנע מהן

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

• שימוש ב-'unsafe-inline' וב-'unsafe-eval': הוראות אלה למעשה מבטלות את ההגנות שמציע CSP ויש להימנע מהן ככל האפשר. השתמשו ב-nonces או ב-hashes עבור סקריפטים מוטבעים והימנעו משימוש ב-eval().
• שימוש ב-*: אישור משאבים מכל מקור מביס את מטרת ה-CSP. היו ספציפיים ככל האפשר בעת הגדרת המדיניות שלכם.
• אי ביצוע בדיקות יסודיות: בדקו תמיד את ה-CSP שלכם במצב דיווח בלבד לפני אכיפתו. נטרו את הדוחות והתאימו את המדיניות שלכם לפי הצורך.
• הגדרה שגויה של report-uri: ודאו שנקודת הקצה של ה-report-uri שלכם מוגדרת כראוי לקבל ולעבד דוחות CSP.
• אי עדכון ה-CSP שלכם: ככל שהאתר שלכם מתפתח, ייתכן שיהיה צורך לעדכן את ה-CSP שלכם כדי לשקף שינויים בתלויות המשאבים שלכם.
• מדיניות מגבילה מדי: מדיניות מגבילה מדי עלולה לשבור את האתר שלכם ולתסכל משתמשים. מצאו איזון בין אבטחה לשימושיות.

CSP וספריות צד שלישי

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

הנה כמה אסטרטגיות לטיפול בספריות צד שלישי:

• הוספה מפורשת לרשימה הלבנה של דומיינים של ספקי צד שלישי מהימנים: לדוגמה, אם אתם משתמשים ב-jQuery מ-CDN, הוסיפו את הדומיין של ה-CDN להוראת script-src שלכם.
• שימוש ב-Subresource Integrity (SRI): SRI מאפשר לכם לוודא שהקבצים שאתם טוענים ממקורות צד שלישי לא שונו. כדי להשתמש ב-SRI, עליכם ליצור hash קריפטוגרפי של הקובץ ולכלול אותו בתג <script> או <link>.
• שקלו לארח ספריות צד שלישי בשרת שלכם: זה נותן לכם יותר שליטה על המשאבים ומפחית את התלות שלכם בספקים חיצוניים.

דוגמה לשימוש ב-SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP ויישומי עמוד יחיד (SPAs)

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

• הימנעו משימוש ב-'unsafe-eval': יישומי SPAs משתמשים לעתים קרובות במנועי תבניות (templating engines) או בטכניקות אחרות המסתמכות על eval(). במקום זאת, שקלו להשתמש בגישות חלופיות שאינן דורשות eval(), כגון תבניות שעברו קומפילציה מראש.
• השתמשו ב-nonces או ב-hashes עבור סקריפטים מוטבעים: יישומי SPAs מזריקים לעתים קרובות קוד JavaScript באופן דינמי. השתמשו ב-nonces או ב-hashes כדי להבטיח שרק קוד מהימן יורץ.
• הגדירו בזהירות את הוראת connect-src: יישומי SPAs מבצעים לעתים קרובות בקשות API לנקודות קצה שונות. ודאו שאתם מוסיפים לרשימה הלבנה רק את הדומיינים הדרושים בהוראת connect-src.
• שקלו להשתמש במסגרת (framework) מודעת ל-CSP: כמה מסגרות JavaScript מספקות תמיכה מובנית ב-CSP, מה שמקל על יישום ותחזוקה של מדיניות מאובטחת.

CSP ובינאום (i18n)

בעת פיתוח יישומי רשת לקהל גלובלי, חשוב לקחת בחשבון את השפעת ה-CSP על בינאום (i18n). הנה כמה גורמים שיש לזכור:

• רשתות אספקת תוכן (CDNs): אם אתם משתמשים ב-CDN כדי לספק את נכסי האתר שלכם, ודאו שאתם מוסיפים את הדומיינים של ה-CDN לרשימה הלבנה ב-CSP שלכם. שקלו להשתמש ב-CDNs שונים לאזורים שונים כדי לייעל את הביצועים.
• גופנים חיצוניים: אם אתם משתמשים בגופנים חיצוניים (למשל, Google Fonts), ודאו שאתם מוסיפים את הדומיינים של ספקי הגופנים לרשימה הלבנה בהוראת font-src שלכם.
• תוכן מותאם מקומית (Localized): אם אתם מגישים גרסאות שונות של האתר שלכם לשפות או אזורים שונים, ודאו שה-CSP שלכם מוגדר כראוי עבור כל גרסה.
• שילובים של צד שלישי: אם אתם משתלבים עם שירותי צד שלישי הספציפיים לאזורים מסוימים, ודאו שאתם מוסיפים את הדומיינים של שירותים אלה לרשימה הלבנה ב-CSP שלכם.

שיטות עבודה מומלצות ל-CSP: פרספקטיבה גלובלית

הנה כמה שיטות עבודה מומלצות כלליות ליישום CSP, תוך התחשבות בפרספקטיבה גלובלית:

• התחילו עם מדיניות מגבילה: התחילו עם מדיניות שחוסמת הכל כברירת מחדל ולאחר מכן אפשרו באופן סלקטיבי מקורות מהימנים.
• השתמשו תחילה במצב דיווח בלבד: בדקו את ה-CSP שלכם במצב דיווח בלבד לפני אכיפתו כדי לזהות בעיות פוטנציאליות.
• נטרו דוחות CSP: סקרו באופן קבוע דוחות CSP כדי לזהות פגיעויות אבטחה פוטנציאליות ולשפר את המדיניות שלכם.
• השתמשו ב-nonces או ב-hashes עבור סקריפטים מוטבעים: הימנעו משימוש ב-'unsafe-inline' וב-'unsafe-eval'.
• היו ספציפיים ברשימות המקור שלכם: הימנעו משימוש בתווים כלליים (*) אלא אם כן זה הכרחי לחלוטין.
• השתמשו ב-Subresource Integrity (SRI) עבור משאבי צד שלישי: ודאו את תקינות הקבצים הנטענים מ-CDNs.
• שמרו על ה-CSP שלכם מעודכן: סקרו ועדכנו את ה-CSP שלכם באופן קבוע כדי לשקף שינויים באתר ובתלויות שלכם.
• הדריכו את הצוות שלכם: ודאו שהמפתחים וצוות האבטחה שלכם מבינים את חשיבות ה-CSP וכיצד ליישם אותו נכון.
• שקלו להשתמש במחולל או כלי ניהול CSP: כלים אלה יכולים לעזור לכם ליצור ולתחזק את ה-CSP שלכם בקלות רבה יותר.
• תעדו את ה-CSP שלכם: תעדו את מדיניות ה-CSP שלכם ואת הסיבות מאחורי כל הוראה כדי לעזור למפתחים עתידיים להבין ולתחזק אותה.

סיכום

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

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

מקורות נוספים

• מדיניות אבטחת תוכן (CSP) - MDN Web Docs
• מעריך CSP
• Content-Security-Policy.com