הסבר מהיר על כותרות אבטחה

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

Eiji Kitamura

Artur Janc

Maud Nalpas

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

כותרות אבטחה מומלצות לאתרים שמטפלים בנתונים רגישים של משתמשים:: Content Security Policy‏ (CSP); Trusted Types
כותרות אבטחה מומלצות לכל האתרים:: X-Content-Type-Options; X-Frame-Options; Cross-Origin Resource Policy (CORP); Cross-Origin Opener Policy (COOP); HTTP Strict Transport Security (HSTS)
כותרות אבטחה לאתרים עם יכולות מתקדמות:: שיתוף משאבים בין מקורות (CORS); Cross-Origin Embedder Policy (COEP)

איומים מוכרים באינטרנט

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

הגנה על האתר מפני נקודות חולשה שמאפשרות הזרקת קוד

פרצות אבטחה מסוג הזרקה מתרחשות כשנתונים לא מהימנים שעוברים עיבוד באפליקציה יכולים להשפיע על ההתנהגות שלה, ולרוב מובילים להרצת סקריפטים שנשלטים על ידי תוקף. פרצת האבטחה הנפוצה ביותר שנגרמת על ידי באגים של הזרקה היא cross-site scripting (XSS) בצורות השונות שלה, כולל reflected XSS,‏ stored XSS,‏ DOM-based XSS וגרסאות אחרות.

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

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

כדי לצמצם את הסיכון להחדרת קוד, כדאי להשתמש במדיניות אבטחת תוכן (CSP) כדי לשלוט בסקריפטים שהאפליקציה יכולה להריץ.
משתמשים בסוגים מהימנים כדי לאכוף חיטוי של נתונים שמועברים לממשקי API מסוכנים של JavaScript.
כדי למנוע מהדפדפן לפרש לא נכון את סוגי ה-MIME של המשאבים באתר, מה שעלול להוביל להפעלת סקריפט, צריך להשתמש בX-Content-Type-Options.

בידוד האתר מאתרים אחרים

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

בין נקודות החולשה הנפוצות שמערערות את הבידוד של אתרים: הונאת קליקים, גניבת זהות משתמש - Cross-Site Request Forgery‏ (CSRF), הכללת סקריפט באתרים שונים (XSSI) ודליפות מידע באתרים שונים.

כדי למנוע הטמעה של המסמכים שלכם באתר זדוני, צריך להשתמש ב-X-Frame-Options.
כדי למנוע הכללה של משאבים מהאתר שלכם באתר ממקור אחר, צריך להשתמש במדיניות משאבים בין מקורות (CORP).
כדאי להשתמש במדיניות של פתיחה ממקורות שונים (COOP) כדי להגן על החלונות של האתר מפני אינטראקציות עם אתרים זדוניים.
אפשר להשתמש בשיתוף משאבים בין מקורות (CORS) כדי לשלוט בגישה למשאבים של האתר ממסמכים ממקורות שונים.

אם אתם מתעניינים בכותרות האלה, מומלץ לקרוא את המאמר Post-Spectre Web Development.

בניית אתר עוצמתי ומאובטח

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

כדי להפעיל בידוד ממקורות שונים, משתמשים במדיניות הטמעה ממקורות שונים (COEP) יחד עם COOP.

הצפנת התנועה לאתר

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

הצפנה לא מספקת יכולה להתרחש במקרים הבאים: לא נעשה שימוש ב-HTTPS, יש תוכן מעורב, קובצי Cookie מוגדרים ללא המאפיין Secure(או הקידומת __Secure), או שיש לוגיקה רופפת של אימות CORS.

משתמשים ב-HTTP Strict Transport Security ‏ (HSTS) כדי להציג את התוכן באופן עקבי דרך HTTPS.

Content Security Policy‏ (CSP)

פרצת אבטחה XSS‏ (cross-site scripting) היא מתקפה שבה נקודת חולשה באתר מאפשרת להחדיר ולהפעיל סקריפט זדוני.

‫Content-Security-Policy מספק שכבת הגנה נוספת לצמצום הסיכון למתקפות XSS על ידי הגבלת הסקריפטים שהדף יכול להריץ.

מומלץ להפעיל CSP מחמיר באחת מהדרכים הבאות:

אם אתם מעבדים את דפי ה-HTML בשרת, צריך להשתמש ב-CSP מחמיר מבוסס-nonce.
אם קובץ ה-HTML צריך להיות מוגש באופן סטטי או מאוחסן במטמון, למשל אם מדובר באפליקציה של דף יחיד, צריך להשתמש ב-CSP מחמיר מבוסס גיבוב (hash).

דוגמה לשימוש: CSP מבוסס-nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

איך משתמשים ב-CSP

שימושים מומלצים

1. שימוש ב-CSP מחמיר שמבוסס על nonce {: #nonce-based-csp}

אם אתם מעבדים את דפי ה-HTML בשרת, צריך להשתמש ב-CSP מחמיר מבוסס-nonce.

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

קובץ תצורת השרת

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

כדי לטעון את הסקריפטים ב-HTML, צריך להגדיר את המאפיין nonce של כל התגים <script> לאותו מחרוזת {RANDOM1}.

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

‫Google Photos היא דוגמה טובה ל-CSP מחמיר שמבוסס על nonce. כדי לראות איך משתמשים בו, אפשר להיעזר בכלי הפיתוח.

2. שימוש ב-CSP מחמיר שמבוסס על גיבוב {: #hash-based-csp}

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

קובץ תצורת השרת

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

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

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

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

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

דפדפנים נתמכים

‫

* https: הוא חלופה ל-Safari ו-unsafe-inline הוא חלופה לגרסאות ישנות מאוד של דפדפנים. התגים https: ו-unsafe-inline לא יפגעו באבטחת המדיניות כי דפדפנים שתומכים ב-strict-dynamic יתעלמו מהם. מידע נוסף זמין במאמר הוספת חלופות לתמיכה ב-Safari ובדפדפנים ישנים יותר. ‫* Safari עדיין לא תומך ב-strict-dynamic. אבל מדיניות CSP מחמירה כמו בדוגמאות שלמעלה בטוחה יותר ממדיניות CSP של רשימת היתרים (ובטוחה הרבה יותר מאי-שימוש במדיניות CSP בכלל) עבור כל המשתמשים. גם ב-Safari, מדיניות CSP מחמירה מגנה על האתר מפני סוגים מסוימים של מתקפות XSS, כי נוכחות מדיניות CSP אוסרת על דפוסים לא בטוחים מסוימים.

הערות נוספות לגבי CSP

‫frame-ancestors ההוראה מגינה על האתר מפני הונאת קליקים – סיכון שמתעורר אם מאפשרים לאתרים לא מהימנים להטמיע את האתר שלכם. אם אתם מעדיפים פתרון פשוט יותר, אתם יכולים להשתמש ב-X-Frame-Options כדי לחסום את הטעינה, אבל frame-ancestors מאפשר לכם להגדיר הגדרה מתקדמת כדי לאפשר רק למקורות ספציפיים להטמיע את התוכן.
יכול להיות שהשתמשתם ב-CSP כדי לוודא שכל המשאבים באתר נטענים באמצעות HTTPS. השיטה הזו פחות רלוונטית היום כי רוב הדפדפנים חוסמים תוכן מעורב.
אפשר גם להגדיר CSP במצב דיווח בלבד.
אם אי אפשר להגדיר CSP ככותרת בצד השרת, אפשר גם להגדיר אותו כמטא תג. שימו לב שאי אפשר להשתמש במצב דיווח בלבד לתגי מטא (אבל יכול להיות שזה ישתנה).

מידע נוסף

סוגים מהימנים

XSS מבוסס-DOM הוא מתקפה שבה נתונים זדוניים מועברים ל-sink שתומך בהרצת קוד דינמי, כמו eval() או .innerHTML.

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

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

שימושים לדוגמה

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;

איך משתמשים בסוגים מהימנים

שימושים מומלצים

החלת Trusted Types על יעד DOM מסוכן כותרת CSP ו-Trusted Types:
```
Content-Security-Policy: require-trusted-types-for 'script'
```
כרגע, הערך הקביל היחיד להנחיית require-trusted-types-for הוא 'script'.

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

מיזוג של CSP מבוסס-nonce מהדוגמה שלמעלה עם Trusted Types:

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;


<aside class="note"><b>הערה: </b>  אפשר להגביל את שמות המדיניות המותרים של סוגים מהימנים על ידי הגדרת הנחיה נוספת של <code>trusted-types</code> (לדוגמה, <code>trusted-types myPolicy</code>). עם זאת, זה לא חובה.</aside>  </aside>


  
    הגדרת מדיניות
    מדיניות:
    
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    הערה:  אפשר להגדיר מדיניות עם שמות שרירותיים, אלא אם מגבילים את השמות של מדיניות מסוגים מהימנים מותרים על ידי הגדרת ההנחיה trusted-types. 
  
  
    החלת המדיניות
    שימוש במדיניות כשכותבים נתונים ל-DOM:
    
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    ב-require-trusted-types-for 'script', חובה להשתמש בסוג מהימן. שימוש במחרוזת עם כל API מסוכן של DOM יגרום לשגיאה.
  

דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
מידע נוסף

  מניעת פרצות אבטחה מסוג XSS‏ (cross-site scripting) מבוסס-DOM באמצעות Trusted Types
  CSP: require-trusted-types-for - HTTP |
      MDN
  CSP: trusted-types - HTTP |
      MDN
  הדגמה של סוגים מהימנים – פותחים את כלי הבדיקה של כלי הפיתוח ורואים מה קורה



X-Content-Type-Options

כשמסמך HTML זדוני מוגש מהדומיין שלכם (לדוגמה, אם תמונה שהועלתה לשירות תמונות מכילה תגי עיצוב HTML תקינים), דפדפנים מסוימים יתייחסו אליו כמסמך פעיל ויאפשרו לו להריץ סקריפטים בהקשר של האפליקציה, מה שיוביל לפרצת אבטחה XSS‏ (cross-site scripting).

‫X-Content-Type-Options: nosniff מונע את זה על ידי הנחיה לדפדפן שסוג ה-MIME שמוגדר בכותרת Content-Type לתגובה מסוימת הוא נכון. מומלץ להשתמש בכותרת הזו לכל המשאבים.

דוגמה לשימוש
X-Content-Type-Options: nosniff


  
    
    איך משתמשים ב-X-Content-Type-Options


    
      שימושים מומלצים
מומלץ להשתמש ב-X-Content-Type-Options: nosniff לכל המשאבים שמוצגים מהשרת שלכם, יחד עם הכותרת הנכונה Content-Type.

דוגמה לכותרות שנשלחו עם מסמך HTML
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  X-Content-Type-Options - HTTP MDN

    
  


X-Frame-Options

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

‫X-Frame-Options מציין אם דפדפן צריך לקבל אישור להצגת דף ב-<frame>,‏ <iframe>,‏ <embed> או <object>. מומלץ לשלוח את הכותרת הזו לכל המסמכים כדי לציין אם הם מאפשרים הטמעה במסמכים אחרים.

הערה:   אם אתם צריכים שליטה פרטנית יותר, למשל לאפשר רק למקור ספציפי להטמיע את המסמך, השתמשו בהנחיית CSP frame-ancestors.  

דוגמה לשימוש
X-Frame-Options: DENY


  
    
    איך משתמשים ב-X-Frame-Options


    
      שימושים מומלצים
בכל המסמכים שלא מיועדים להטמעה צריך להשתמש בכותרת X-Frame-Options.
אתם יכולים לנסות איך ההגדרות הבאות משפיעות על טעינת iframe בהדגמה הזו. משנים את התפריט הנפתח X-Frame-Options
  ולוחצים על הלחצן טעינה מחדש של ה-iframe.
הגנה על האתר מפני הטמעה באתרים אחרים
למנוע הטמעה במסמכים אחרים.

X-Frame-Options: DENY
הגנה על האתר מפני הטמעה על ידי אתרים ממקורות שונים
ההרשאה להטמעה ניתנת רק למסמכים מאותו מקור.
X-Frame-Options: SAMEORIGIN
 העובדה שהמסמכים ניתנים להטמעה כברירת מחדל מחייבת את מפתחי האתרים לשלוח במפורש DENY או SAMEORIGIN כדי להפסיק את ההטמעה ולהגן על עצמם מפני מתקפות בערוץ צדדי. צוות Chrome שוקל לעבור לחסימה של הטמעות מסמכים כברירת מחדל, כדי שאתרים יהיו מאובטחים גם אם הם לא מגדירים את הכותרת באופן מפורש. בעולם החדש הזה, כדי להטמיע מסמכים צריך להביע הסכמה מפורשת. 
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  X-Frame-Options - HTTP

    
  


מדיניות משאבים ממקורות שונים (CORP)

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

Cross-Origin-Resource-Policy מצמצם את הסיכון הזה על ידי ציון קבוצת האתרים שמהם אפשר לטעון אותו. הכותרת מקבלת אחד משלושת הערכים הבאים: same-origin,‏ same-site ו-cross-origin. מומלץ לשלוח את הכותרת הזו לכל המשאבים כדי לציין אם הם מאפשרים טעינה על ידי אתרים אחרים.

דוגמה לשימוש
Cross-Origin-Resource-Policy: same-origin


  
    
    איך משתמשים ב-CORP


    
      שימושים מומלצים
מומלץ להציג את כל המשאבים עם אחת משלוש הכותרות הבאות.
כדי לראות איך ההגדרות הבאות משפיעות על טעינת משאבים בסביבת Cross-Origin-Embedder-Policy: require-corp, אפשר לנסות את ההדגמה הזו. משנים את התפריט הנפתח Cross-Origin-Resource-Policy ולוחצים על הכפתור Reload the iframe או Reload the image כדי לראות את האפקט.

התרת טעינת משאבים cross-origin
מומלץ ששירותים כמו CDN יחילו cross-origin על משאבים (כי בדרך כלל הם נטענים על ידי דפים ממקורות שונים), אלא אם הם כבר מוגשים דרך CORS, שיש לו השפעה דומה.

Cross-Origin-Resource-Policy: cross-origin
הגבלת המשאבים שנטענים מ-same-origin
צריך להחיל את same-origin על משאבים שמיועדים לטעינה רק על ידי דפים מאותו מקור. צריך להחיל את ההגדרות האלה על משאבים שכוללים מידע רגיש על המשתמש, או על תגובות של API שמיועד לקריאה רק מאותו מקור.
חשוב לזכור שעדיין אפשר לטעון ישירות משאבים עם הכותרת הזו, למשל על ידי ניווט לכתובת ה-URL בחלון חדש של הדפדפן. מדיניות שיתוף משאבים בין מקורות (CORS) מגנה רק על המשאב מפני הטמעה באתרים אחרים.

Cross-Origin-Resource-Policy: same-origin
הגבלת המשאבים שנטענים מ-same-site
מומלץ להחיל את same-site על משאבים שדומים לאלה שלמעלה, אבל מיועדים לטעינה על ידי תת-דומיינים אחרים באתר.

Cross-Origin-Resource-Policy: same-site
הערה:  כדי לקבל מידע נוסף על ההבדל בין same-origin לבין same-site, אפשר לעיין במאמר הסבר על same-site ו-same-origin. 
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  כדאי לפרוס מדיניות משאבים חוצי-מקורות
  הגדרת האתר כ-cross-origin isolated באמצעות COOP ו-COEP
  למה צריך 'חסום לגישה מדומיינים אחרים' כדי להשתמש בתכונות מתקדמות

    
  


מדיניות פותחן מרובת מקורות (COOP)

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

הכותרת Cross-Origin-Opener-Policy מאפשרת למסמך לבודד את עצמו מחלונות ממקורות שונים שנפתחו דרך window.open() או קישור עם target="_blank" בלי rel="noopener". כתוצאה מכך, לכל חלון קופץ שייפתח ממקור אחר לא תהיה הפניה למסמך, ולא תהיה לו אפשרות ליצור איתו אינטראקציה.

דוגמה לשימוש
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    איך משתמשים ב-COOP


    
      שימושים מומלצים
אפשר לנסות את ההגדרות הבאות כדי לראות איך הן משפיעות על התקשורת עם חלון קופץ חוצה-מקורות בהדגמה הזו.
  משנים את התפריט הנפתח Cross-Origin-Opener-Policy (מדיניות פתיחה חוצת מקורות) גם במסמך וגם בחלון הקופץ, לוחצים על הלחצן Open a popup (פתיחת חלון קופץ) ואז על Send a postMessage (שליחת הודעה) כדי לבדוק אם ההודעה באמת נמסרה.
בידוד מסמך מחלונות חוצי-מקורות
ההגדרה same-origin מבודדת את המסמך מחלונות מסמכים ממקורות שונים.

Cross-Origin-Opener-Policy: same-origin
בידוד מסמך מחלונות ממקורות שונים, אבל מתן אפשרות להצגת חלונות קופצים
ההגדרה same-origin-allow-popups מאפשרת למסמך לשמור הפניה לחלונות הקופצים שלו, אלא אם הם מגדירים COOP עם same-origin או same-origin-allow-popups. כלומר, same-origin-allow-popups עדיין יכול להגן על המסמך מפני הפניה אליו כשהוא נפתח כחלון קופץ, אבל לאפשר לו לתקשר עם החלונות הקופצים שלו.


Cross-Origin-Opener-Policy: same-origin-allow-popups
אפשר להפנות למסמך מחלונות חוצי-מקורות
‫unsafe-none הוא ערך ברירת המחדל, אבל אפשר לציין במפורש שאפשר לפתוח את המסמך הזה בחלון ממקור אחר ולשמור על גישה הדדית.
 unsafe-none כברירת מחדל, מפתחי אתרים צריכים לשלוח same-origin או same-origin-allow-popups באופן מפורש כדי להגן על האתר שלהם מפני מתקפות בערוץ צדדי. 
Cross-Origin-Opener-Policy: unsafe-none
הערה:  תכונות כמו SharedArrayBuffer או performance.measureUserAgentSpecificMemory() מושבתות כברירת מחדל. בדפדפנים מסוימים אפשר להשתמש בהם בהקשרים של 'חסום לגישה מדומיינים אחרים', שבהם נדרש להגדיר כותרות COOP ו-COEP. מידע נוסף זמין במאמר בנושא הגדרת האתר כ'חסום לגישה מדומיינים אחרים' באמצעות COOP ו-COEP. 
דפוסי דיווח שלא תואמים ל-COOP
אתם יכולים לקבל דוחות כשהמדיניות COOP מונעת אינטראקציות בין חלונות עם Reporting API.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
בנוסף, COOP תומך במצב דיווח בלבד, כך שתוכלו לקבל דוחות בלי לחסום בפועל את התקשורת בין מסמכים ממקורות שונים.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  למה צריך 'חסום לגישה מדומיינים אחרים' כדי להשתמש בתכונות מתקדמות

    
  


שיתוף משאבים בין מקורות (CORS)

בניגוד לפריטים אחרים במאמר הזה, שיתוף משאבים בין מקורות (CORS) הוא לא כותרת, אלא מנגנון בדפדפן שמבקש ומאפשר גישה למשאבים ממקורות שונים.

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

דוגמה לשימוש
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true


  
    
    איך משתמשים ב-CORS


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

  השיטה היא GET, HEAD או POST.
  הכותרות המותאמות אישית כוללות רק את Accept, Accept-Language,
    Content-Language ו-Content-Type.
  
  הערך בעמודה Content-Type הוא application/x-www-form-urlencoded, ‏multipart/form-data או text/plain.
  

כל השאר מסווג כבקשה עם בדיקת היתכנות. פרטים נוספים זמינים במאמר שיתוף משאבים בין מקורות (CORS) – HTTP | MDN.
שימושים מומלצים
בקשה פשוטה
כשבקשה עומדת בקריטריונים של בקשה פשוטה, הדפדפן שולח בקשת CORS עם כותרת Origin שמציינת את המקור של הבקשה.
דוגמה לכותרת הבקשה
Get / HTTP/1.1
Origin: https://example.com
כותרת תגובה לדוגמה
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

  ‫Access-Control-Allow-Origin: https://example.com מציין ש-https://example.com יכול לגשת לתוכן התשובה. משאבים שנועדו להיות קריאים לכל אתר יכולים להגדיר את הכותרת הזו לערך *. במקרה כזה, הדפדפן ידרוש שהבקשה תתבצע ללא פרטי כניסה.
  
  הערך Access-Control-Allow-Credentials: true מציין שבקשות שכוללות פרטי כניסה (קובצי Cookie) יכולות לטעון את המשאב. אחרת, בקשות מאומתות יידחו גם אם המקור של הבקשה מופיע בכותרת Access-Control-Allow-Origin.

אתם יכולים לנסות איך הבקשה הפשוטה משפיעה על טעינת משאבים בסביבת Cross-Origin-Embedder-Policy: require-corp הדגמה הזו. מסמנים את התיבה שיתוף משאבים בין מקורות ולוחצים על הלחצן Reload the image כדי לראות את האפקט.

בקשות עם בדיקה מקדימה
לפני בקשת קדם-הפעלה נשלחת בקשת OPTIONS כדי לבדוק אם מותר לשלוח את הבקשה הבאה.
דוגמה לכותרת הבקשה
OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

  ‫Access-Control-Request-Method: POST מאפשרת לשלוח את הבקשה הבאה באמצעות שיטת POST.
  ‫Access-Control-Request-Headers: X-PINGOTHER, Content-Type מאפשר למגיש הבקשה להגדיר את כותרות ה-HTTP‏ X-PINGOTHER ו-Content-Type בבקשה הבאה.

כותרות של תגובות לדוגמה
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

  התגובה Access-Control-Allow-Methods: POST, GET, OPTIONS מציינת שאפשר לשלוח בקשות נוספות באמצעות השיטות POST, GET ו-OPTIONS.
  ‫Access-Control-Allow-Headers: X-PINGOTHER, Content-Type מציין שבבקשות הבאות אפשר לכלול את הכותרות X-PINGOTHER ו-Content-Type.
  ‫Access-Control-Max-Age: 86400 מציין שאפשר לשמור במטמון את התוצאה של בקשת preflight למשך 86,400 שניות.

דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  שיתוף משאבים בין מקורות (CORS)
  שיתוף משאבים בין מקורות (CORS) – HTTP |
      MDN

    
  


מדיניות כלי להטמעה ממקורות שונים (COEP)

כדי לצמצם את היכולת של מתקפות מבוססות Spectre לגנוב משאבים ממקורות שונים, תכונות כמו SharedArrayBuffer או performance.measureUserAgentSpecificMemory() מושבתות כברירת מחדל.

Cross-Origin-Embedder-Policy: require-corp מונעת טעינה של מסמכים ועובדים של משאבים ממקורות שונים, כמו תמונות, סקריפטים, גיליונות סגנונות, מסגרות iframe ועוד, אלא אם המשאבים האלה מאשרים באופן מפורש את הטעינה שלהם באמצעות כותרות CORS או CORP. אפשר לשלב את COEP עםCross-Origin-Opener-Policy
כדי להפעיל בידוד ממקורות שונים במסמך.

משתמשים ב-Cross-Origin-Embedder-Policy: require-corp כשרוצים להפעיל חסימה לגישה מדומיינים אחרים למסמך.

דוגמה לשימוש
Cross-Origin-Embedder-Policy: require-corp


  
    
    איך משתמשים ב-COEP


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


כדי לראות איך ההגדרות הבאות משפיעות על טעינת המשאבים, אפשר לנסות את ההדגמה הזו. משנים את התפריט הנפתח Cross-Origin-Embedder-Policy, את התפריט הנפתח Cross-Origin-Resource-Policy, את תיבת הסימון Report Only וכו', כדי לראות איך הם משפיעים על טעינת המשאבים. בנוסף, כדאי לפתוח את הדמו של נקודת הקצה של הדיווח כדי לבדוק אם המשאבים החסומים מדווחים.

הפעלת בידוד חוצה-דומיינים
כדי להפעיל בידוד מרובה מקורות, שולחים את
  Cross-Origin-Embedder-Policy: require-corp יחד עם
  Cross-Origin-Opener-Policy: same-origin.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
דיווח על משאבים שלא תואמים ל-COEP
אפשר לקבל דוחות על משאבים חסומים שנגרמו על ידי COEP באמצעות Reporting API.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
בנוסף, COEP תומך במצב דיווח בלבד, כך שתוכלו לקבל דוחות בלי לחסום את טעינת המשאבים.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  הגדרת האתר כ-cross-origin isolated באמצעות COOP ו-COEP
  למה צריך 'חסום לגישה מדומיינים אחרים' כדי להשתמש בתכונות מתקדמות
  מדריך להפעלת חסימה לגישה מדומיינים אחרים

    
  


HTTP Strict Transport Security ‏ (HSTS)

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

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

דוגמה לשימוש
Strict-Transport-Security: max-age=31536000


  
    
    איך משתמשים ב-HSTS


    
      שימושים מומלצים
כל האתרים שעוברים מ-HTTP ל-HTTPS צריכים להגיב עם כותרת Strict-Transport-Security כשמתקבלת בקשה עם HTTP.

Strict-Transport-Security: max-age=31536000
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
מידע נוסף

  Strict-Transport-Security -
      HTTP

    
  


קריאה נוספת


Post-Spectre Web Development

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

הגנה על האתר מפני נקודות חולשה שמאפשרות הזרקת קוד

בידוד האתר מאתרים אחרים

בניית אתר עוצמתי ומאובטח

הצפנת התנועה לאתר

Content Security Policy‏ (CSP)

שימושים מומלצים

1. שימוש ב-CSP מחמיר שמבוסס על nonce {: #nonce-based-csp}

2. שימוש ב-CSP מחמיר שמבוסס על גיבוב {: #hash-based-csp}

דפדפנים נתמכים

הערות נוספות לגבי CSP

מידע נוסף

סוגים מהימנים

שימושים מומלצים

דפדפנים נתמכים

מידע נוסף

X-Content-Type-Options

שימושים מומלצים

דפדפנים נתמכים

מידע נוסף

X-Frame-Options

שימושים מומלצים

הגנה על האתר מפני הטמעה באתרים אחרים

הגנה על האתר מפני הטמעה על ידי אתרים ממקורות שונים

דפדפנים נתמכים

מידע נוסף

מדיניות משאבים ממקורות שונים (CORP)

שימושים מומלצים

התרת טעינת משאבים cross-origin

הגבלת המשאבים שנטענים מ-same-origin

הגבלת המשאבים שנטענים מ-same-site

דפדפנים נתמכים

מידע נוסף

מדיניות פותחן מרובת מקורות (COOP)

שימושים מומלצים

בידוד מסמך מחלונות חוצי-מקורות

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

אפשר להפנות למסמך מחלונות חוצי-מקורות

דפוסי דיווח שלא תואמים ל-COOP

דפדפנים נתמכים

מידע נוסף

שיתוף משאבים בין מקורות (CORS)

שימושים מומלצים

בקשה פשוטה

בקשות עם בדיקה מקדימה

דפדפנים נתמכים

מידע נוסף

מדיניות כלי להטמעה ממקורות שונים (COEP)

דוגמאות לשימוש

הפעלת בידוד חוצה-דומיינים

דיווח על משאבים שלא תואמים ל-COEP

דפדפנים נתמכים

מידע נוסף

HTTP Strict Transport Security ‏ (HSTS)

שימושים מומלצים

דפדפנים נתמכים

מידע נוסף

קריאה נוספת

הסבר מהיר על כותרות אבטחה

התרת טעינת משאבים `cross-origin`

הגבלת המשאבים שנטענים מ-`same-origin`

הגבלת המשאבים שנטענים מ-`same-site`