"शीर्ष-असुरक्षित-अनुरोध" HTTP हेडर क्या है?

Question

मैंने एक HTTP (गैर-HTTPS) साइट के लिए एक POST अनुरोध किया, Chrome के डेवलपर टूल में अनुरोध का निरीक्षण किया, और पाया कि इसे सर्वर पर भेजने से पहले उसने अपना हेडर जोड़ा:

Upgrade-Insecure-Requests: 1

पर खोज करने के बाद Upgrade-Insecure-Requests, मैं केवल इस हेडर को भेजने वाले सर्वर के बारे में जानकारी पा सकता हूं :

Content-Security-Policy: upgrade-insecure-requests

यह संबंधित प्रतीत होता है, लेकिन फिर भी मेरे मामले में बहुत भिन्न है, CLIENT अनुरोध में शीर्ष लेख भेज रहा है, जबकि मैंने जो भी जानकारी प्राप्त की है, वह एक प्रतिक्रिया में संबंधित शीर्षक भेजने वाले SERVER के बारे में है ।

---

तो Chrome Upgrade-Insecure-Requestsमेरे अनुरोध में क्यों शामिल है (44.0.2403.130 मीटर) और यह क्या करता है?

---

अपडेट 2016-08-24:

इस हेडर को तब से W3C कैंडिडेट की सिफारिश के रूप में जोड़ा गया है और अब इसे आधिकारिक रूप से मान्यता प्राप्त है।

उन लोगों के लिए जो अभी इस सवाल पर आए थे और भ्रमित हैं, साइमन ईस्ट का उत्कृष्ट उत्तर इसे अच्छी तरह से समझाता है।

Upgrade-Insecure-Requests: 1हैडर हुआ करता था HTTPS: 1 पिछले W3C कार्यकारी ड्राफ्ट में और नाम दिया गया था चुपचाप से पहले परिवर्तन आधिकारिक तौर पर स्वीकार किए जाते हैं बन गया क्रोम द्वारा।

(यह सवाल इस संक्रमण के दौरान पूछा गया था जब इस हेडर पर कोई आधिकारिक दस्तावेज नहीं थे और क्रोम एकमात्र ब्राउज़र था जिसने इस हेडर को भेजा था)।

Comments

फ़ायरफ़ॉक्स भी करता है।

— dakab

नया होना चाहिए; मैं पहले फ़ायरफ़ॉक्स पर विकास करता हूं और यह हेडर निश्चित रूप से पिछले साल फ़ायरफ़ॉक्स से नहीं भेजा गया था।

— user193130

Answer 1

संक्षिप्त उत्तर: यह Content-Security-Policy: upgrade-insecure-requestsप्रतिक्रिया हेडर से निकटता से संबंधित है , यह दर्शाता है कि ब्राउज़र इसका समर्थन करता है (और वास्तव में इसे पसंद करता है)।

यह मुझे Googling के 30 मीटर तक ले गया, लेकिन मैंने आखिरकार इसे डब्ल्यू 3 कल्पना में दफन कर दिया।

भ्रम इसलिए आता है क्योंकि कल्पना में हेडर था HTTPS: 1, और इसी तरह क्रोमियम ने इसे लागू किया, लेकिन इसके बाद बहुत सारी वेबसाइटें खराब हो गईं जिन्हें कोडित किया गया था (विशेष रूप से वर्डप्रेस और वूकॉम) क्रोमियम टीम ने माफी मांगी:

"मैं टूटने के लिए माफी माँगता हूँ, मैंने स्पष्ट रूप से देव और बीटा के दौरान प्रतिक्रिया के आधार पर प्रभाव को कम करके आंका।"
- माइक वेस्ट, क्रोम इश्यू 501842 में

उनका निर्धारण इसे फिर से नाम देना था Upgrade-Insecure-Requests: 1, और तब से कल्पना को मैच के लिए अद्यतन किया गया है।

वैसे भी, यहाँ डब्ल्यू 3 कल्पना से स्पष्टीकरण है (जैसा कि यह उस समय दिखाई दिया) ...

HTTPSHTTP अनुरोध हेडर क्षेत्र सर्वर के लिए एक संकेत भेजता है ग्राहक की वरीयता व्यक्त एक एन्क्रिप्टेड और प्रमाणीकृत प्रतिक्रिया के लिए, और कहा कि इसे सफलतापूर्वक संभाल कर सकते हैं उन्नयन-असुरक्षित-अनुरोध निर्देश ताकि अधिक से सहज उपलब्ध कराने के लिए के रूप में है कि वरीयता बनाने के लिए।

...

जब एक सर्वर HTTP अनुरोध के हेडर में इस प्राथमिकता का सामना करता है, तो यह उपयोगकर्ता को अनुरोध किए जा रहे संसाधन के संभावित सुरक्षित प्रतिनिधित्व के लिए पुनर्निर्देशित करता है।

जब कोई सर्वर HTTPS अनुरोध के शीर्ष Strict-Transport-Securityलेख में इस वरीयता का सामना करता है, तो यह प्रतिक्रिया के होस्ट के HSTS- सुरक्षित या सशर्त रूप से HSTS- सुरक्षित [RFC6797] होने पर प्रतिक्रिया में एक शीर्षक शामिल करता है।

Comments

मैं इसे समझने में असफल हूं। इस शीर्षक को प्रदान करने और कुछ जानकारी भेजने के दौरान, मैं a.comआपको पुनः निर्देशित करूंगा । यदि आप किसी सुरक्षित चैनल के अंतर्गत नहीं हैं , तो एक सूँघने-हमला पहले से ही हो सकता है, क्योंकि मैंने अपने अनुरोध के साथ डेटा भेजा है । क्या आप हमें एक सरल परिदृश्य के लिए मार्गदर्शन कर सकते हैं कि कैसे यह उपयोगकर्ताओं के लिए कनेक्शन को अधिक सुरक्षित बनाता है? b.comb.comb.comb.com

— सईद नेमाटी

@SaeedNeamati एक बहुत ही सख्त परिप्रेक्ष्य के तहत यह कुछ भी अधिक सुरक्षित नहीं करता है। यदि आपके पास सामान्य सुरक्षा आवश्यकताएं हैं, तो आपको यह सुनिश्चित करना होगा कि आप पहले HTTPS के माध्यम से कनेक्ट हों और इस पर भरोसा न करें। यह कहा जा रहा है, मैं इसका वर्णन " ट्रस्ट ऑन फर्स्ट यूज " के विचार के संदर्भ में करूंगा , जो निष्क्रिय रूप से मदद करता है ।

— tn

मैं इसे सुरक्षा उपकरण से ग्राहक की इच्छा के रूप में अधिक देखता हूं। यह "डीएनटी" हेडर की तरह है, सर्वर इसे अनदेखा कर सकता है, लेकिन फिर भी यह क्लाइंट की इच्छा को व्यक्त करता है।

— डेजुन

मेरे उत्तर को वास्तव में यह समझाने के लिए बेहतर किया जा सकता है कि क्लाइंट और सर्वर इस पर कैसे बातचीत करते हैं। यदि आप चाहें तो सुधारों का सुझाव देने के लिए स्वतंत्र महसूस करें।

— साइमन ईस्ट

Answer 2

यह पूरी बात समझाता है:

HTTP सामग्री-सुरक्षा-नीति (CSP) नवीनीकरण-असुरक्षित-अनुरोध निर्देश उपयोगकर्ता एजेंटों को साइट के सभी असुरक्षित URL (HTTP पर सेवा करने वाले) के साथ व्यवहार करने का निर्देश देता है, क्योंकि उन्हें सुरक्षित URL (HTTPS के साथ सेवा करने वाले) से बदल दिया गया है। यह निर्देश बड़ी संख्या में असुरक्षित विरासत URL वाले वेब साइटों के लिए है, जिन्हें फिर से लिखने की आवश्यकता है।

उन्नयन-असुरक्षित-अनुरोध के निर्देश का मूल्यांकन ब्लॉक-ऑल-मिक्स-कंटेंट से पहले किया जाता है और यदि इसे सेट किया गया है, तो उत्तरार्द्ध प्रभावी रूप से एक नो-ऑप है। यह एक निर्देश या दूसरे को निर्धारित करने की सिफारिश की जाती है, लेकिन दोनों नहीं।

उन्नयन-असुरक्षित-अनुरोध निर्देश यह सुनिश्चित नहीं करेगा कि तृतीय-पक्ष साइटों पर लिंक के माध्यम से आपकी साइट पर आने वाले उपयोगकर्ताओं को शीर्ष-स्तरीय नेविगेशन के लिए HTTPS में अपग्रेड किया जाएगा और इस तरह यह सख्त-परिवहन-सुरक्षा (HSTS) हेडर को प्रतिस्थापित नहीं करता है, जो उपयोगकर्ताओं को SSL स्ट्रिपिंग हमलों के अधीन नहीं हैं यह सुनिश्चित करने के लिए अभी भी एक उचित अधिकतम आयु के साथ सेट किया जाना चाहिए।

स्रोत: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrad-insecure-requests