2009-09-01 14 views
36

कुछ परीक्षणों के बाद, मैं इस निष्कर्ष तक पहुंचने के लिए शुरू कर रहा हूं कि जब कोई https https से किसी HTTP पृष्ठ पर क्लिक करता है तो कोई ब्राउज़र रेफरर HTTP शीर्षलेख नहीं भेजता है।HTTP शीर्षलेख रेफरर HTTP पृष्ठ से किसी http पृष्ठ पर जाने पर भेजा गया है?

इसके लिए सुरक्षा कारण क्या है? मानक में कहीं परिभाषित किया गया है?

+0

के बाद इस पोस्ट पाया किसी भी मामले में यह पूरी तरह से ग्राहक अगर Referer या सेट किया जाना चाहिए नहीं पर निर्भर है में करने के लिए उपयोगी होगा। –

+1

@ ब्रायन: लेकिन ग्राहकों को आरएफसी का उपयोग कर रहे प्रोटोकॉल को परिभाषित करना चाहिए/उनका सम्मान करना चाहिए। –

+0

वर्तमान स्वीकृत उत्तर एक अच्छा जवाब है, लेकिन यह @ avid के उत्तर जैसा ही था जिसे पहले पोस्ट किया गया था। – mikemaccana

उत्तर

53

HTTP RFC राज्यों, खंड 15.1.3 Encoding Sensitive Information in URI's में:

ग्राहकों को संदर्भित पृष्ठ एक सुरक्षित प्रोटोकॉल के साथ स्थानांतरित होने पर एक रेफरर हेडर फ़ील्ड को एक (गैर-सुरक्षित) HTTP अनुरोध में शामिल नहीं करना चाहिए।

तो, यह अपेक्षित/मानक व्यवहार है।

+2

ठीक है, तो कैसे और क्यों Google https से गैर-सुरक्षित साइटों पर रेफरर भेजता है? – confiq

+2

@confiq क्योंकि यह कहता है 'नहीं होना चाहिए'? –

17

हाँ, standard में परिभाषित:

ग्राहक एक (गैर-सुरक्षित) HTTP अनुरोध में एक Referer हेडर फ़ील्ड शामिल नहीं होना चाहिए अगर जिक्र पेज सुरक्षित प्रोटोकॉल

साथ स्थानांतरित किया गया था
+2

मैं थोड़ा सा स्पष्टीकरण जोड़ूंगा, https urls में अक्सर संवेदनशील जानकारी होती है, जैसे कि sessionid, खाता संख्या, आदि। बेशक यह एसएसएल पर भी बुरा है, लेकिन यह अभी भी किया गया है ... और वैसे भी, HTTPS सत्र आमतौर पर संवेदनशील अनुप्रयोग होते हैं, उस जानकारी को अनिवार्य रूप से बेनकाब करने का कोई कारण नहीं है। – AviD

4

कारण: कभी-कभी सत्र आईडी यूआरएल एन्कोडेड होते हैं। HTTP पन्ने में क्रॉस साइट स्क्रिप्टिंग हो सकती है जो एचटीटीपीएस संचार से सत्र चुराती है। इसे रोकने के लिए, संदर्भकर्ता HTTPS पर HTTP संक्रमण पर प्रेषित नहीं होता है ताकि यूआरएल एन्कोडेड एससिन आईडी चोरी नहीं हो सके।

+0

सेशन http -> https के लिए पूछ रहा है, इसके विपरीत नहीं। – dsas

+2

@dsas "जब कोई https एक से http पृष्ठ पर क्लिक करता है" का अर्थ है https -> http, http -> https नहीं। –

+0

@ जॉन पिक आप बिल्कुल सही हैं, मुझे यकीन नहीं है कि मैं इसे कैसे गलत तरीके से पढ़ता हूं। – dsas

19

असल में यह w3c document on referrer policy के अनुसार, सीधे आगे नहीं है (2014 के बाद)।

डिफ़ॉल्ट व्यवहार यह है कि ब्राउज़र HTTPS से HTTP पर जाने पर संदर्भकर्ता जानकारी नहीं भेजेगा। हालांकि, HTTPS से HTTPS तक जाने पर ब्राउज़र रेफरर भेज देंगे।

<meta name="referrer" content="origin"> 

New browsers have already implemented this:

इसके अलावा, एचटीएमएल 5 में, वहाँ एक नया मेटा रेफरर नामित टैग, कि इस तरह दिखता है है। तो क्या ब्राउज़र रेफरर भेज देगा या नहीं, निकट भविष्य में इस मेटा टैग पर निर्भर करेगा। यदि यह मेटा टैग पृष्ठ के HTML में शामिल नहीं है, तो ब्राउज़र डिफ़ॉल्ट व्यवहार का उपयोग करेंगे।

बाद रेफरर मेटा टैग की सामग्री विशेषता के संभावित मान हैं:

  • कोई रेफरर: संदर्भ, नहीं भेजा जाएगा HTTP या HTTPS
  • मूल की परवाह किए बिना: केवल मूल (मुख्य) डोमेन रेफरर रूप में भेजा जाएगा
  • मूल-जब-crossorigin: वही मूल पूर्ण संदर्भ URL और पार मूल भेज रेफरर के रूप में केवल मूल URL भेजेगा
  • कोई रेफरर-जब-ढाल देगा: इस डिफ़ॉल्ट व्यवहार तब होता है जब कोई रेफरर पेज पर मेटा टैग प्रदान किया जाता है।
  • असुरक्षित-यूआरएल: यह हमेशा HTTP की है, तो संदर्भ भेज देंगे परवाह किए बिना या HTTPS

इसके अलावा, वहाँ कुछ विरासत हैं रेफरर मेटा टैग के लिए विशेषता मान।ये नहीं रह सिफारिश कर रहे हैं, लेकिन इस समय कई साइटों में इस्तेमाल किया:

  • हमेशा कोई-रेफरर-जब-ढाल के रूप में ही:

    • कभी नहीं: कोई रेफरर के रूप में ही
    • डिफ़ॉल्ट असुरक्षित रूप में एक ही -url

    मुझे आशा है कि इस जानकारी को कोई है जो सिर्फ 2014

  • +0

    अच्छा संकेत। हालांकि यह सभी उपकरणों पर काम नहीं करता है। :(पीसी/मैक में क्रोम ठीक काम करता है लेकिन ** एंडोरिड ** में क्रोम काम नहीं करता है! – Kane

    संबंधित मुद्दे