Defaults.Exposed › תיקונים › HSTS (Strict-Transport-Security)

כיצד לתקן HSTS (Strict-Transport-Security)

HSTS היא הוראה בשורה אחת שהאתר שלך נותן לכל דפדפן: 'חזור אלי תמיד דרך החיבור המאובטח והמוצפן — לא דרך הלא מאובטח.' בלעדיה, המנעול שלך יכול להיחטף בשקט ב-Wi-Fi משותפת, והביקור הראשון הראשון לאתר שלך חשוף.

השורה התחתונה לעסק שלכם: קיום HTTPS (המנעול) אינו זהה לאכיפתו. ללא HSTS, תוקף באותה Wi-Fi כמו הלקוח שלך יכול להוריד בשקט את החיבור ל-HTTP פשוט ולא מוצפן — תופס כניסות, פרטי כרטיס ונתוני טפסים בעוד הלקוח לא רואה כלום רע. תעודת ה-SSL שלך, שאולי אתה משלם עליה, מעוקפת. התיקון חינמי ולוקח כ-15 דקות למי שמנהל את האתר.

מה זה יכול לעלות לכם

• לקוחות ב-Wi-Fi של בית קפה, מלון, שדה תעופה, או כנס יכולים שהחיבור שלהם לאתר שלך יורד ונתוניהם נקראים — ללא כל אזהרה על המסך שלהם.
• שילמת על HTTPS ויש לך את המנעול, אבל ללא HSTS תוקפים יכולים פשוט לנתב מסביב אליו; התעודה נותנת תחושת ביטחון מזויפת.
• הביקור הראשון לאתר שלך (לפני כל הפניה ל-HTTPS) הוא נקודת התורפה שתוקפים מכוונים אליה — HSTS היא מה שסוגרת אותה לכל ביקור חוזר.
• שאלון אבטחה, טופס ביטוח סייבר, או רשימת בדיקה של קונה ארגוני מסמנים 'אין HSTS' ועוצרים את העסקה עד לתיקון.
• הגדר את הערך בצורה שגויה (קצר מדי) ותקבל את הגרוע משני העולמות: נראה מוגדר אבל מספק כמעט ללא הגנה אמיתית.

מדוע זה חשוב. HTTPS מגן על חיבור לאחר שהוא מוצפן — אבל הוא אינו מאלץ דפדפנים להשתמש בו. תוקפים מנצלים את הפרצה הזו עם 'SSL stripping': בכל רשת משותפת הם שומרים בשקט על המבקר ב-HTTP פשוט וקוראים הכל. HSTS אומר לדפדפן לסרב לחלוטין ל-HTTP הפשוט לדומיין שלך, לזמן רב, כך שהפרצה נסגרת לאחר הביקור הראשון. זוהי כותרת תגובה אחת, חינמית להוספה, ובניקוד שלנו היא שווה ניקוד אמיתי כי ערך חסר או קצר מדי משאיר כל מבקר ב-Wi-Fi ציבורית חשוף.

מה זה, בשפה פשוטה

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

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

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

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

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

מה זה יכול לעלות לך

אלה תרחישים ריאליים מהחיים.

1. ההקלה בבית הקפה. לקוח פותח את החנות שלך ב-Wi-Fi של בית הקפה ומגיע לשלב התשלום. תוקף באותה רשת מריץ כלי חינמי ידוע שמשאיר את הלקוח ב-HTTP פשוט במקום HTTPS. הלקוח רואה מה שנראה כאתר הרגיל שלך — ללא אזהרה, ללא מנעול שבור — ומקליד פרטי הכרטיס שלו. התוקף קורא כל הקשה. תעודת ה-SSL שלך לא עשתה כלום, כי החיבור מעולם לא הורשה להפוך למאובטח.

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

3. העסקה שנעצרת. לקוח גדול שולח לך את שאלון האבטחה הסטנדרטי שלו לפני החתימה. שורה אחת שואלת: “האם האתר שלך אוכף HTTPS דרך HSTS?” איש ה-IT שלך צריך לענות “לא”, ותהליך הרכש מושהה בזמן שאתה מתרוצץ לתקן הגדרה חינמית של 15 דקות שעכשיו נראית כדגל אדום בפני קונה.

4. בדיקת ביטוח הסייבר או הציות. סריקת מבטח, או רואה חשבון שבודק את מצב הגנת הנתונים שלך, מסמנת את הכותרת החסרה. הצפנת נתונים אישיים היא ציפייה מפורשת לפי כללי הגנת נתונים (GDPR Article 32), ו”יש לנו תעודה אבל לא אוכפים אותה” הוא מקום חלש מאוד לעמוד בו.

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

החוט המשותף: העלות אינה מופשטת. זה כרטיס או כניסה אמיתית של לקוח אמיתי, נתפסת ברגע הגרוע ביותר, ללא כל אזעקה.

מה זה בעצם

כשדפדפן מבקש מהאתר שלך דף, השרת שלך שולח בחזרה את הדף בנוסף לכמה “כותרות” בלתי נראות — הוראות נוספות שהדפדפן קורא אבל המבקר לעולם לא רואה. HSTS היא אחת מאותן כותרות:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

שלושה חלקים חשובים:

• max-age — כמה זמן (בשניות) הדפדפן צריך לזכור לאכוף HTTPS. 31536000 היא שנה אחת. זהו לב ליבו: קצר מדי ולא עוזר כמעט.
• includeSubDomains — הרחב את הכלל לכל תת-דומיין (shop., app., mail. וכו’), לא רק לכתובתך הראשית.
• preload — הירשם לרשימה ראשית שמובנית לדפדפנים, כך שהגנה חלה אפילו בבקשה הראשונה של המבקר, לפני שמעולם ראה את האתר שלך.

למה “הביקור הראשון” חשוב

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

מה נראה “טוב” — וכיצד הוא מנוקד

הבדיקה שלנו קוראת את הכותרת החיה שלך ומדרגת את max-age:

כך כותרת קיימת אבל מוגדרת לכמה דקות נחשבת כשל — היא נראית מוגדרת אבל לא עושה את העבודה. כוון לשנה אחת. הבדיקה גם מציינת האם includeSubDomains ו-preload קיימים.

כיצד לתקן (חינם, ~15 דקות)

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

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

שלב 1 — ודא שHTTPS כבר עובד בכל מקום

בקר באתר שלך ובתתי-דומיינים מרכזיים ב-https:// ואשר שהם נטענים בצורה נקייה עם תעודה חוקית. גם אשר שבקשות http:// פשוטות מופנות ל-https://. (אם לא, תקן תחילה את הפניית ה-HTTP-ל-HTTPS — HSTS מניח שהיא קיימת.)

שלב 2 — הוסף את הכותרת (בחר את הפלטפורמה שלך)

Cloudflare (או CDN דומה): זה הכי קל. עבור ל-SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) ואפשר אותה. הגדר Max-Age ל-6 חודשים או 12 חודשים, ואפשר “Apply HSTS policy to subdomains” ברגע שאתה בטוח שכל תתי-הדומיינים על HTTPS.

Nginx: הוסף בתוך בלוק ה-HTTPS server שלך:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache: ודא ש-mod_headers מופעל, ואז הוסף למארח הווירטואלי ה-HTTPS שלך:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS: הוסף ל-web.config בתוך <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

הערה Google Workspace / Microsoft 365: אלה מניעים את הדואר שלך, לא את אירוח האתר שלך — HSTS נקבע היכן שהאתר הציבורי שלך חי בפועל (ה-CDN שלך, שרת האינטרנט, או בונה האתר), לא בלוח הניהול של Workspace/365.

שלב 3 — בדוק קטן, ואז התחייב

התחל עם max-age=300 (5 דקות). אשר שהאתר עדיין נטען בצורה מושלמת בכל מקום. ואז הרם ל-max-age=31536000 (שנה אחת). זוהי ההגדרה עם ניקוד מלא.

שלב 4 (אופציונלי, סטנדרט זהב) — preload

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

טעויות נפוצות

• הגדרת max-age קצר מדי. ערך של כמה דקות או שעות נראה מוגדר אבל מספק כמעט ללא הגנה — והבדיקה שלנו מתייחסת לכל דבר מתחת ליום ככשל. השתמש בשנה.
• הפעלת includeSubDomains לפני שתתי-הדומיינים מוכנים ל-HTTPS. אם תת-דומיין אינו לחלוטין ב-HTTPS, הכלל הדביק יכול לגרום לו להיות לא ניתן להגעה למבקרים. העבר כל תת-דומיין ל-HTTPS תחילה.
• הוספת HSTS אבל ללא הפניית HTTP-ל-HTTPS. HSTS מניח שמבקרים מגיעים לגרסה המאובטחת; ללא ההפניה, הביקור הראשון חשוף שלא לצורך. תקן את שניהם יחד.
• קפיצה ישירה ל-preload כדי “להיות יסודי.” Preload קשה לביטול. השג אותו בהדרגה לאחר כותרת יציבה לשנה — אל תמהר בזה.
• הנחה שהמנעול מכסה אותך כבר. המנעול ו-HSTS הם דברים שונים. יכולה להיות לך תעודה מושלמת ועדיין לכשול בבדיקה זו.

שאלות נפוצות