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 विनंती वाहकाकडून काहीही मिळवू शकली नाही. संसाधनाचा मार्ग दुरुस्त करा आणि ब्राउझरची अंमलबजावणी जागच्या जागी ठेवा. असुरक्षित अवलंबनाची दुरुस्ती म्हणून आणखी एक वाहतूक स्तर गणणे हाच तो मार्ग आहे ज्याने संघ शेवटी योग्यरित्या काम करणारे नियंत्रण बंद करणाऱ्या हेल्पडेस्क स्क्रिप्टपर्यंत पोहोचतो.

संबंधित लेख