אבטחת אתר – HTTP Headers

מבוא

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

המבנה של HTTP Headers:

HTTP Headers הם מידע המועבר בין הדפים והשרת כחלק מבקשות ותגובות ה-HTTP. הם מתחלקים לשני חלקים עיקריים: השורה הראשונה (Status Line או Request Line) והשורות התחתונות. השורה הראשונה מכילה את הקוד המציין את המצב של הבקשה או התגובה, כמו 200 OK לדוגמה.

שימושים נפוצים ב-HTTP Headers

1. Cache Control: על ידי הגדרת ערכים ב-headers כמו Cache-Control ו-Expires, ניתן לשלוט על המטמון בדפים ולהפגיש בין ביצועיות לסיכוניות עדכונים.
2. User-Agent: ה-User-Agent הוא ערך ב-header המזהה את הדפדפן או היישום שמבקש את הדף. בהשוואה ל-User-Agent ניתן להציב תנאים שונים לטעינת תוכן או לפעולות באתר, לפי התכנים הספציפיים לכל סוג דפדפן.
3. Location: במידה ונרצה להפנות את הלקוח לכתובת אחרת, ניתן להשתמש ב-header בשם "Location" בתגובה עם קוד מצב 3xx.
4. Content-Type: ה-header Content-Type מציין את סוג המידע שנשלח בגוף הבקשה או התגובה, כמו טקסט, תמונות, או וידאו. זה מסייע לדפדפנים להבין כיצד להציג את התוכן המקושר.

החשיבות של אבטחת ה-HTTP Headers:

1. זיהוי ומניעת התקפות: נכון הגדרות ב-HTTP Headers יכולות למנוע התקפות כמו חסימת קריצת ערך (Cross-Site Scripting, XSS) וגניבת זהות (Cross-Site Request Forgery, CSRF), הניצחו בפופולריותם בפלטפורמות הרשת.
2. הגנה מהפרטיות והצפנת מידע: הגדרות ב-HTTP Headers כמו ניהול של ספריות מטמון והחלפת ה-HTTP ל-HTTPS יכולות להגן על המידע הרגיש הנשלח בין הלקוח לשרת מפני גניבה או גילוי.
3. תקשורת בטוחה: בצורה כמו הגדרת Strict-Transport-Security, ניתן לוודא שהגולשים מתקשרים עם השרת באמצעות חיבור מאובטח (SSL/TLS), מונע כך תקשורת מותקפת ופרטים הנשלחים לא יוכלו להיגנב.

בדיקות אבטחה של HTTP Headers

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

נקודת מוצא – תוצאות

Content Security Policy (CSP)

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

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

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

הגדרת CSP היה תהליך הכי מאתר בכל ההגדרות, בגלל שאתר מתבסס על סקריפטים חיצוניים או קוד שהוא inline. והגדרה של source ברירת מחדש default-src 'self' היפילה את האתר ברמת התמונות ואינטאקטיביות.

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

• תמונות (img-src) – רוב התמונות שלי מתבססות על שרת עצמי, למעט כמה שמתבססות על data.
• עיצובים (style-src) – הגדרות יחסית פשוטות, עיצובים נטענים בעיקר בקובץ css או כחלק מHTML.
• סקריפטים (script-src) – כנ״ל, לא מדובר במשהו מורכב ומתבצע באותם שורות, קוד אינליין וקבצים על אותה הכתובת של האתר.

 Header set Content-Security-Policy "default-src 'self';"
Header set Content-Security-Policy "style-src  'self' 'unsafe-inline';" 
Header set Content-Security-Policy "img-src 'self';" 
Header set Content-Security-Policy "script-src 'self' data: 'unsafe-inline';" 

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

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

 Header set Content-Security-Policy "default-src 'self'"
Header set Content-Security-Policy "style-src  'self' 'unsafe-inline' fonts.googleapis.com" 
Header set Content-Security-Policy "img-src 'self' data: *.google-analytics.com *.googletagmanager.com;" 
Header set Content-Security-Policy "script-src 'self' data: 'unsafe-inline' *.googletagmanager.com *.google-analytics.com;"
Header set Content-Security-Policy "font-src fonts.gstatic.com;"
Header set Content-Security-Policy "connect-src *.google-analytics.com *.google.com *.googletagmanager.com *.doubleclick.net;" 

יש לשים לב להגדרות CSP בקפידה, כי כל דבר יכול לשבש את פעילות האתר או תצוגה של תוכן ברמות שונות. אני התמודדתי עם Font Face, Tag Manager ועוד כמה דברים קטנים, לכל משאב פנימי וחיצוני צריך להגדיר את ההגדרות הקטנות. לדוגמה הטמעה של וידאו, טעינה של וידאו מיוטיוב וכו…

X-Content-Type-Options

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

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

 Header set X-Content-Type-Options nosniff 

X-Frame-Options

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

 Header set X-Content-Type-Options nosniff 

Strict-Transport-Security (HSTS)

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

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

 Header set Strict-Transport-Security: max-age=31536000 

Referrer Policy

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

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

 Header set Referrer-Policy: no-referrer-when-downgrade 

Permissions Policy

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

 Header set Permissions-Policy: geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=() 

X-XSS-Protection

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

 Header set X-XSS-Protection "1; mode=block" 

תוצאות סופיות

לאחר סיום כל האופטימיזציה, הגעתי לתוצאות טובות ועברתי את כל הבדיקות למעט CSP במוזילה. הבעיה המרכזית מבחינת אבטחה שלהם כל משאבים שמשפיעים על האתר צריכים להיות בקבצים החיצוניים (ללא inline code) אז ההורידו לי 20 נקודות על זה.

קוד סופי

קוד מלא htaccess

 <ifModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'"
Header set Content-Security-Policy "style-src  'self' 'unsafe-inline' fonts.googleapis.com" 
Header set Content-Security-Policy "img-src 'self' data: *.google-analytics.com *.googletagmanager.com;" 
Header set Content-Security-Policy "script-src 'self' data: 'unsafe-inline' *.googletagmanager.com *.google-analytics.com;"
Header set Content-Security-Policy "font-src fonts.gstatic.com;"
Header set Content-Security-Policy "connect-src 'self' *.google-analytics.com *.google.com *.googletagmanager.com *.doubleclick.net;"
Header set X-Content-Type-Options nosniff
Header set X-Frame-Options SAMEORIGIN
Header set Strict-Transport-Security: "max-age=31536000" env=HTTPS
Header set Referrer-Policy: no-referrer-when-downgrade
Header set Permissions-Policy: geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()
Header set X-XSS-Protection "1; mode=block"
</ifModule> 

קוד מלא ngnix

 location / {
        add_header Content-Security-Policy "default-src 'self';";
        add_header Content-Security-Policy "style-src 'self' 'unsafe-inline' fonts.googleapis.com";
        add_header Content-Security-Policy "img-src 'self' data: *.google-analytics.com *.googletagmanager.com";
        add_header Content-Security-Policy "script-src 'self' data: 'unsafe-inline' *.googletagmanager.com *.google-analytics.com";
        add_header Content-Security-Policy "font-src fonts.gstatic.com";
        add_header Content-Security-Policy "connect-src 'self' *.google-analytics.com *.google.com *.googletagmanager.com *.doubleclick.net";
        add_header X-Content-Type-Options nosniff;
        add_header X-Frame-Options SAMEORIGIN;
        add_header Strict-Transport-Security "max-age=31536000" always; # 'always' even if not HTTPS
        add_header Referrer-Policy "no-referrer-when-downgrade";
        add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()";
        add_header X-XSS-Protection "1; mode=block";
        
        # Add PHP FastCGI settings if needed
        # location ~ \.php$ {
        #     include snippets/fastcgi-php.conf;
        #     fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        # }
    } 

קוד לוורדרפס

 function custom_security_headers($headers) {
    $headers['Content-Security-Policy'] = "default-src 'self';";
    $headers['Content-Security-Policy'] .= " style-src 'self' 'unsafe-inline' fonts.googleapis.com;";
    $headers['Content-Security-Policy'] .= " img-src 'self' data: *.google-analytics.com *.googletagmanager.com;";
    $headers['Content-Security-Policy'] .= " script-src 'self' data: 'unsafe-inline' *.googletagmanager.com *.google-analytics.com;";
    $headers['Content-Security-Policy'] .= " font-src fonts.gstatic.com;";
    $headers['Content-Security-Policy'] .= " connect-src 'self' *.google-analytics.com *.google.com *.googletagmanager.com *.doubleclick.net;";
    $headers['X-Content-Type-Options'] = "nosniff";
    $headers['X-Frame-Options'] = "SAMEORIGIN";
    $headers['Strict-Transport-Security'] = "max-age=31536000";
    $headers['Referrer-Policy'] = "no-referrer-when-downgrade";
    $headers['Permissions-Policy'] = "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()";
    $headers['X-XSS-Protection'] = "1; mode=block";
    return $headers;
}
add_filter('wp_headers', 'custom_security_headers'); 

סיכום ומסכנות

ללא ספק נושא של אבטחה תמיד מצריך שיפור ותחזוקה תמידית, יחד עם את זאת לא כל הדרישות של אבטחה ניתנות ליישום באתרים תדמיתיים שלא מחזיקים מידע נוסף אתר על משתמשים. בדיקות של Observatory פסלו את כל הטיפול בקאשינג של LiteSpeed ואת הדחיסה של CSS, מבחינת הכלי, כל inline code הוא פתח לפריצה. זה מתנגד לטפיסה של טעינת Critical CSS.
תפקידנו להחליט מה עדיף, פסילה של כלי אבטחה (בדברים מינוריים) או פסילה של זמני טעינה.


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

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