VPN के पीछे मिश्रित सामग्री: संसाधन ठीक करें, सुरंग नहीं
ताला दस्तावेज़ का वर्णन करता है, उसकी लोड की गई स्क्रिप्ट का नहीं। कंसोल पढ़ें, अवरोध बनाए रखें, संदर्भ को उसके स्रोत पर ठीक करें, फिर पृष्ठ का पुनः परीक्षण करें।
HTTP से स्क्रिप्ट लोड करने वाला HTTPS पृष्ठ दो अलग-अलग सुरक्षा स्तरों के साथ दो अनुरोध करता है, और ताला केवल पहले का वर्णन करता है। सुरंग इसे नहीं बदलती, क्योंकि वह वाहक की रक्षा करती है, संसाधन की अपनी स्कीम की नहीं। यदि आप पता-पट्टी के बजाय कंसोल पढ़ें तो ब्राउज़र पहले ही बता रहा है कि कौन-सा अनुरोध विफल हुआ। तीन जाँचें आपको आधे काम करने वाले पृष्ठ से वास्तविक मरम्मत तक ले जाती हैं।
अनुरोध पढ़ें, पता-पट्टी नहीं
HTTPS से लाया गया दस्तावेज़ सादे HTTP से किसी स्क्रिप्ट, स्टाइलशीट, फ़ॉन्ट या फ़्रेम का संदर्भ दे सकता है। वह संदर्भ एक अलग अनुरोध है, और ब्राउज़र उसी की शिकायत करता है। मुख्य दस्तावेज़ की सुरक्षा उसमें वापस नहीं जाती, और दोनों प्रवाहों को ले जाने वाली सुरंग दोनों में से कोई स्कीम नहीं बदलती। इसलिए पृष्ठ एक ही समय में वास्तव में सुरक्षित और वास्तव में टूटा हुआ हो सकता है।
संसाधन को केवल एक शामिल फ़ाइल कहना उसके प्रतिस्थापन को हानिरहित नहीं बनाता।
यदि असुरक्षित स्क्रिप्ट सामग्री को रास्ते में बदला जा सके और फिर चलाया जा सके, तो वह पृष्ठ का व्यवहार बदल सकती है, जो सौंदर्य संबंधी विफलता से बड़ी समस्या है। चित्र रास्ते में बदले जाने पर छोटा लेकिन वास्तविक जोखिम रखते हैं। ताला किसी बात पर झूठ नहीं बोलता। यह उस प्रश्न से संकीर्ण प्रश्न का उत्तर दे रहा है जो आपने उससे पूछा था।
जानें कौन-से संसाधन अवरुद्ध होते हैं और कौन-से उन्नत होते हैं
ब्राउज़र हर प्रकार के संसाधन के साथ एक जैसा व्यवहार नहीं करते। मिश्रित सामग्री संबंधी मार्गदर्शन HTTPS पर उन्नत किए जाने वाले अनुरोधों को पूरी तरह अवरुद्ध किए जाने वाले अनुरोधों से अलग करता है, जिसमें स्क्रिप्ट, स्टाइलशीट और प्रोग्रामीय अनुरोध अवरुद्ध पक्ष पर होते हैं, जबकि चित्र और मीडिया इसके बजाय उन्नत या चिह्नित किए जा सकते हैं।
यही अंतर भ्रमित करने वाली रिपोर्टों की व्याख्या करता है। अवरुद्ध स्क्रिप्ट वाला पृष्ठ एक सुविधा पूरी तरह खो देता है, जबकि उन्नत चित्र वाला पृष्ठ ठीक दिखता है और चुपचाप अपना अनुरोध बदल चुका है। प्रलेखित श्रेणियों में अपवाद भी हैं, इसलिए यह न मानें कि किसी दिए गए प्रकार का हर URL सफलतापूर्वक उन्नत होगा। फ़ाइल एक्सटेंशन से तर्क करने के बजाय पढ़ें कि कंसोल विशिष्ट अनुरोध के बारे में क्या कहता है।
अवरुद्ध विजेट इस बात का प्रमाण नहीं है कि सुरंग विफल हुई। यह प्रमाण है कि ब्राउज़र ने अपना काम किया।
संदर्भ को उसके स्रोत पर ठीक करें
साइट के मालिक के लिए मरम्मत वहीं होनी चाहिए जहाँ असुरक्षित URL लिखा गया था: कोई टेम्पलेट, स्टाइलशीट, URL जोड़ने वाली स्क्रिप्ट, या किसी तीसरे पक्ष का घटक। दृश्यमान पृष्ठ पता बदलने से ये सब अछूते रहते हैं। स्रोत में होस्ट खोजें और कंसोल द्वारा संयोग से नामित एक संदर्भ के बजाय हर संदर्भ ठीक करें।
फिर पुष्टि करें कि संसाधन वास्तव में वैध पहचान के साथ HTTPS पर परोसा जाता है, क्योंकि स्कीम बदलाव उस सेवा को नहीं गढ़ सकता जो कभी वहाँ प्रकाशित ही नहीं हुई।
grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1रीडायरेक्ट भी अनुसरण करें, क्योंकि HTTPS से शुरू होने वाला संदर्भ फिर भी सादे पाठ के वितरण पथ पर उतर सकता है। जहाँ किसी निर्भरता के पास सुरक्षित वितरण ही न हो, वहाँ वर्कअराउंड भेजने के बजाय सामान्य परिवर्तन प्रक्रिया से उसे हटाएँ या बदलें। उपयोगकर्ता के लिए ब्राउज़र की सुरक्षाएँ चालू रखें और साइट के मालिक को संसाधन का URL, उसका प्रकार और कंसोल संदेश बताएँ। कभी भी ऐसे निर्देश न फैलाएँ जो कर्मचारियों से एक पृष्ठ के लिए असुरक्षित सामग्री की अनुमति देने को कहें, क्योंकि वह अपवाद उस घटना से अधिक जीता है जिसने उसे जन्म दिया।
पृष्ठ का पुनः परीक्षण वैसे करें जैसे उपयोगकर्ता उसे छूते हैं
माँग पर संसाधन लोड करने वाले संचालनों का अभ्यास करें, केवल पहले दस्तावेज़ का नहीं। बटन दबाने के बाद पृष्ठ अतिरिक्त कोड, डेटा और डाउनलोड लाते हैं, और वे अनुरोध अक्सर असुरक्षित होते हैं। सुरक्षा चालू रहते हुए विशिष्ट अनुरोधों और दृश्यमान व्यवहार की पुष्टि करें। ढीली ब्राउज़र प्रोफ़ाइल से शुरू होने वाला परीक्षण आपको नहीं दिखा सकता कि सामान्य उपयोगकर्ता क्या देखता है।
सुरंग का अपना काम अभी भी है, और वह काम नेटवर्क पहुँच है, पृष्ठ की अखंडता नहीं।
एक बार यातायात सुरंग के अंतिम बिंदु से निकल जाए, तो कोई भी शेष HTTP अनुरोध वाहक से कुछ नहीं पाया। संसाधन का पथ ठीक करें और ब्राउज़र का प्रवर्तन यथावत रखें। असुरक्षित निर्भरता की मरम्मत के रूप में एक और परिवहन परत को मानना ही वह तरीका है जिससे कोई टीम अंततः ऐसी हेल्पडेस्क स्क्रिप्ट तक पहुँचती है जो सही ढंग से काम कर रहे नियंत्रण को बंद कर देती है।