תוכן מעורב מאחורי VPN: לתקן את המשאב, לא את המנהרה
המנעול מתאר את המסמך, לא את הסקריפטים שהוא טוען. קראו את המסוף, שמרו על החסימה, תקנו את ההפניה במקור שלה, ואז בדקו שוב את העמוד.
עמוד HTTPS שטוען סקריפטים דרך HTTP מבצע שתי בקשות בשתי רמות הגנה שונות, והמנעול מתאר רק את הראשונה. מנהרה לא משנה זאת, כי היא מגנה על הנשא ולא על הסכימה של המשאב עצמו. הדפדפן כבר אומר לכם איזו בקשה נכשלה, אם תקראו את המסוף במקום את שורת הכתובת. שלוש בדיקות מובילות אתכם מעמוד שעובד חלקית לתיקון אמיתי.
קראו את הבקשה, לא את שורת הכתובת
מסמך שנמשך דרך HTTPS יכול להפנות לסקריפט, לגיליון סגנונות, לגופן או למסגרת דרך HTTP פשוט. ההפניה הזו היא בקשה נפרדת, והיא זו שהדפדפן מתלונן עליה. ההגנה של המסמך הראשי אינה עוברת אחורה לתוכה, והמנהרה שנושאת את שני הזרמים אינה משנה אף אחת משתי הסכימות. לכן העמוד יכול להיות גם בטוח באמת וגם שבור באמת בעת ובעונה אחת.
לקרוא למשאב סתם קובץ כלול לא הופך את החלפתו לבלתי מזיקה.
אם אפשר לשנות תוכן סקריפט לא מאובטח בדרך ואז להריץ אותו, הוא יכול לשנות את התנהגות העמוד, וזו בעיה גדולה יותר מתקלה קוסמטית. תמונות נושאות סיכון קטן יותר אך אמיתי כשהן משתנות בדרך. המנעול לא משקר על דבר. הוא עונה על שאלה צרה יותר מזו ששאלתם אותו.
דעו אילו משאבים נחסמים ואילו משודרגים
דפדפנים לא מתייחסים לכל סוג משאב באותה צורה. ההנחיות לתוכן מעורב מפרידות בין בקשות שמשודרגות ל-HTTPS לבין בקשות שנחסמות כליל, כאשר סקריפטים, גיליונות סגנונות ובקשות תוכנתיות נמצאים בצד החסום, ואילו תמונות ומדיה עשויות להיות משודרגות או מסומנות במקום.
ההבדל הזה מסביר את הדוחות המבלבלים. עמוד שסקריפט שלו נחסם מאבד תכונה לחלוטין, ואילו עמוד שתמונתו שודרגה נראה תקין ובשקט שינה את בקשתו. לקטגוריות המתועדות יש גם חריגים, אז אל תניחו שכל URL מסוג נתון ישודרג בהצלחה. קראו מה המסוף אומר על הבקשה הספציפית במקום להסיק מסיומת קובץ.
רכיב חסום אינו הוכחה שהמנהרה נכשלה. זו הוכחה שהדפדפן עשה את עבודתו.
תקנו את ההפניה במקור שלה
עבור בעל אתר, התיקון שייך למקום שבו נכתבה הכתובת הלא מאובטחת: תבנית, גיליון סגנונות, סקריפט שמרכיב כתובות URL, או רכיב של צד שלישי. שינוי הכתובת הנראית של העמוד משאיר את כל אלה ללא שינוי. חפשו במקור את המארח ותקנו כל הפניה ולא רק את זו שהמסוף הזכיר במקרה.
אחר כך ודאו שהמשאב אכן מוגש דרך HTTPS עם זהות תקפה, כי החלפת סכימה אינה יכולה להמציא שירות שמעולם לא פורסם שם.
grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1עקבו גם אחרי הפניות מחדש, כי הפניה שמתחילה ב-HTTPS עדיין יכולה לנחות על נתיב אספקה בטקסט פשוט. כאשר לתלות פשוט אין אספקה מאובטחת זמינה, הסירו או החליפו אותה דרך תהליך השינוי הרגיל במקום לספק עקיפה. עבור משתמש, השאירו את הגנות הדפדפן פעילות ו דווחו לבעל האתר את כתובת ה-URL של המשאב, את סוגו ואת הודעת המסוף. לעולם אל תפיצו הוראות שאומרות לצוות לאפשר תוכן לא מאובטח עבור עמוד אחד, כי החריג הזה שורד את התקרית שעוררה אותו.
בדקו שוב את העמוד כפי שמשתמשים נוגעים בו
תרגלו את הפעולות שטוענות משאבים לפי דרישה, לא רק את המסמך הראשון. עמודים מושכים קוד, נתונים והורדות נוספים לאחר לחיצה על כפתור, והבקשות האלה הן לעתים קרובות הלא מאובטחות. אשרו את הבקשות הספציפיות ואת ההתנהגות הנראית כשההגנה עדיין פעילה. בדיקה שמתחילה בפרופיל דפדפן מרופף אינה יכולה להראות לכם מה משתמש רגיל רואה.
למנהרה עדיין יש עבודה משלה, והעבודה הזו היא גישה לרשת ולא שלמות העמוד.
ברגע שהתעבורה עוזבת את נקודת הקצה של המנהרה, שום בקשת HTTP שנותרה לא הרוויחה דבר מהנשא. תקנו את נתיב המשאב והשאירו את האכיפה בדפדפן במקומה. התייחסות לשכבת תעבורה נוספת כתיקון לתלות לא מאובטחת היא הדרך שבה צוות מגיע לסקריפט של מוקד תמיכה שמכבה את הבקרה שעבדה כראוי.