स्कीमफ़ुल सेम-साइट

"एक ही साइट" की परिभाषा यूआरएल स्कीम को शामिल करने के तरीके में बदलाव किया जा रहा है. इसलिए, किसी साइट के एचटीटीपी और एचटीटीपीएस वर्शन के बीच मौजूद लिंक, अब क्रॉस-साइट अनुरोधों के तौर पर गिने जाएंगे. जहां भी हो सके, समस्याओं से बचने के लिए डिफ़ॉल्ट रूप से एचटीटीपीएस पर अपग्रेड करें. इसके अलावा, SameSite एट्रिब्यूट की वैल्यू के बारे में जानने के लिए आगे पढ़ें.

Steven Bingler

Rowan Merewood

स्कीमफ़ुल एक ही साइट वाला यूआरएल (वेब) साइट की परिभाषा को सिर्फ़ रजिस्टर किए जा सकने वाले डोमेन से बदलकर स्कीम + रजिस्टर किया जा सकने वाला डोमेन. ज़्यादा जानकारी और उदाहरण यहां देखें "एक ही साइट" को समझना और "सेम-ऑरिजन" होना चाहिए.

अच्छी खबर यह है कि अगर आपकी वेबसाइट पहले ही पूरी तरह से एचटीटीपीएस पर अपग्रेड हो चुकी है, तो उन्हें किसी चीज़ की चिंता करने की ज़रूरत नहीं है. आपके लिए कुछ भी नहीं बदलेगा.

अगर आपने अभी तक अपनी वेबसाइट को पूरी तरह से अपग्रेड नहीं किया है, तो यही प्राथमिकता होनी चाहिए. हालांकि, अगर ऐसे मामले हैं जहां आपकी साइट पर आने वाले लोग एचटीटीपी और एचटीटीपीएस, फिर उनमें से कुछ सामान्य स्थितियों और उनसे जुड़ी SameSite कुकी व्यवहार की जानकारी नीचे दी गई है.

आप इन बदलावों को Chrome और Firefox, दोनों में टेस्ट करने के लिए चालू कर सकते हैं.

• Chrome 86 से, about://flags/#schemeful-same-site चालू करें. प्रोग्रेस को ट्रैक करें Chrome की स्थिति पेज पर जाएं.
• Firefox 79 से, इसके ज़रिए network.cookie.sameSite.schemeful को true पर सेट करें about:config. Bugzilla के ज़रिए प्रोग्रेस ट्रैक करें समस्या.

इसके लिए SameSite=Lax को डिफ़ॉल्ट के रूप में किए जाने की मुख्य वजहों में से एक कुकी को क्रॉस-साइट अनुरोध की जालसाज़ी से बचाने के लिए किया गया था (सीएसआरएफ). हालांकि, असुरक्षित एचटीटीपी ट्रैफ़िक अब भी नेटवर्क हमलावरों को उन कुकी के साथ छेड़छाड़ करना चाहते हैं जिनका इस्तेमाल बाद में की वेबसाइट पर जाएं. स्कीम के बीच यह अतिरिक्त क्रॉस-साइट सीमा बनाने से आपको कई सुविधाएं मिलती हैं इन हमलों से बचाव के लिए.

क्रॉस-स्कीम की सामान्य स्थितियां

नेविगेशन

किसी वेबसाइट के क्रॉस-स्कीम वर्शन के बीच नेविगेट करना (उदाहरण के लिए, पहले http://site.example से https://site.example तक की अनुमति देता था SameSite=Strict कुकी भेजी जाने हैं. इसे अब एक क्रॉस-साइट के रूप में माना जाता है नेविगेशन का मतलब है कि SameSite=Strict कुकी ब्लॉक कर दी जाएंगी.

सबरिसॉर्स लोड हो रहे हैं

यहां किए जाने वाले किसी भी बदलाव को, कुछ समय के लिए ठीक किया गया प्रॉडक्ट माना जाना चाहिए. ऐसा तब ही करना चाहिए, जब आप पूरे एचटीटीपीएस पर अपग्रेड करने में मेरी मदद करता है.

सबरिसॉर्स के उदाहरणों में इमेज, iframe, और इससे किए गए नेटवर्क अनुरोध शामिल हैं XHR या फे़च.

किसी पेज पर, क्रॉस-स्कीम सबरिसॉर्स लोड करने की अनुमति पहले दी जाती थी भेजने या सेट करने के लिए SameSite=Strict या SameSite=Lax कुकी. अब यह है इसे किसी अन्य तीसरे पक्ष या क्रॉस-साइट सबरिसॉर्स की तरह इस्तेमाल किया जाता है, जो इसका मतलब है कि SameSite=Strict या SameSite=Lax कुकी ब्लॉक कर दी जाएंगी.

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

फ़ॉर्म पोस्ट करना

पहले किसी वेबसाइट के क्रॉस-स्कीम वर्शन के बीच पोस्ट करने की अनुमति थी कुकी को भेजने के लिए, SameSite=Lax या SameSite=Strict के साथ सेट किया गया है. अब यह है इसे क्रॉस-साइट पोस्ट के तौर पर माना जाता है—सिर्फ़ SameSite=None कुकी भेजी जा सकती हैं. आप डिफ़ॉल्ट रूप से असुरक्षित वर्शन वाली साइटों पर भी इस तरह की गड़बड़ी का सामना करना पड़ सकता है, लेकिन साइन-इन सबमिट करने पर उपयोगकर्ताओं को सुरक्षित वर्शन पर अपग्रेड करें या चेक-आउट फ़ॉर्म.

सबरिसॉर्स की तरह, अगर अनुरोध किसी सुरक्षित साइट से किया जा रहा है, जैसे कि एचटीटीपीएस से असुरक्षित, जैसे एचटीटीपी और कॉन्टेक्स्ट के बाद इन अनुरोधों के लिए सभी कुकी ब्लॉक कर दी जाएंगी क्योंकि तीसरे पक्ष या क्रॉस-साइट कुकी के लिए, Secure की ज़रूरत होती है.

मैं अपनी साइट की जांच कैसे करूं?

डेवलपर टूल और मैसेज सेवा, Chrome और Firefox में उपलब्ध हैं.

Chrome 86 से, समस्या टैब में DevTools यह काम करेगा स्कीमफ़ुल समान-साइट वाली समस्याएं शामिल करें. आपको ये समस्याएं हाइलाइट की जा सकती हैं आपकी साइट के लिए.

नेविगेशन से जुड़ी समस्याएं:

• "एक ही साइट पर कुकी भेजना जारी रखने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें अनुरोध"—एक चेतावनी जिसमें बताया जाता है कि आने वाले वर्शन में कुकी को ब्लॉक कर दिया जाएगा वाला है.
• "एक ही साइट के अनुरोधों पर कुकी भेजने के लिए पूरी तरह से एचटीटीपीएस पर माइग्रेट करें"—A चेतावनी: कुकी को ब्लॉक कर दिया गया है.

सबरिसॉर्स लोड होने में आने वाली समस्याएं:

• "उसी साइट पर कुकी भेजना जारी रखने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें उपसंसाधन" या "पूरी तरह से एचटीटीपीएस पर माइग्रेट करें, ताकि कुकी को 'एक ही साइट के सबरिसॉर्स' से सेट की जाएंगी"—चेतावनी कि कुकी को Chrome के आने वाले वर्शन में ब्लॉक किया गया.
• "पूरी तरह एचटीटीपीएस पर माइग्रेट करें, ताकि कुकी एक ही साइट के सबरिसॉर्स पर भेजी जा सकें" या "कुकी को एक ही साइट से सेट करने की अनुमति देने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें सबरिसॉर्स"—चेतावनी कि कुकी को ब्लॉक कर दिया गया है. बाद वाला फ़ॉर्म पोस्ट करते समय भी चेतावनी दिख सकती है.

स्कीमफ़ुल के लिए, जांच और डीबग करने की सलाह वाले पेज पर ज़्यादा जानकारी उपलब्ध है एक ही साइट का इस्तेमाल करना.

Firefox 79 से, network.cookie.sameSite.schemeful के साथ true पर सेट किया गया about:config कंसोल, स्कीमफ़ुल सेम-साइट की समस्याओं के लिए मैसेज दिखाएगा. आपको अपनी साइट पर ये चीज़ें दिख सकती हैं:

• "कुकी cookie_name को जल्द ही क्रॉस-साइट कुकी के तौर पर माना जाएगा http://site.example/ क्योंकि स्कीम मेल नहीं खाती."
• "कुकी cookie_name को के ख़िलाफ़ क्रॉस-साइट माना गया है http://site.example/ क्योंकि स्कीम मेल नहीं खाती."

अक्सर पूछे जाने वाले सवाल

मेरी साइट पहले से ही एचटीटीपीएस पर उपलब्ध है. मुझे अपने ब्राउज़र के DevTools में समस्याएं क्यों दिख रही हैं?

ऐसा हो सकता है कि आपके कुछ लिंक और सबरिसॉर्स अब भी असुरक्षित पेज पर ले जाएं यूआरएल.

इस समस्या को हल करने का एक तरीका यह है कि आप एचटीटीपी सख्त-परिवहन-सुरक्षा (HSTS) और includeSubDomain डायरेक्टिव. एचएसटीएस + includeSubDomain के साथ अगर आपके किसी पेज में गलती से असुरक्षित लिंक शामिल हो जाता है, तो ब्राउज़र सुरक्षित वर्शन का अपने-आप इस्तेमाल करें.

अगर मुझे एचटीटीपीएस पर अपग्रेड नहीं किया जा सका, तो क्या होगा?

हमारा सुझाव है कि आप अपनी साइट को पूरी तरह से एचटीटीपीएस पर अपग्रेड करें, ताकि अपने उपयोगकर्ताओं को सुरक्षित रखें, अगर आप खुद ऐसा नहीं कर सकते, तो हमारा सुझाव है कि आप देख सकता है कि क्या वे वह विकल्प ऑफ़र कर सकते हैं. अगर आपको इस सुविधा को खुद होस्ट करना है, तो इसके बाद, Let’s Encrypt को कई टूल मिलते हैं, किसी सर्टिफ़िकेट को इंस्टॉल और कॉन्फ़िगर किया जा सकता है. साइट को एक जगह से दूसरी जगह ले जाने के बारे में, एचटीटीपीएस कनेक्शन उपलब्ध कराने वाले सीडीएन या अन्य प्रॉक्सी का इस्तेमाल करना.

अगर अब भी ऐसा नहीं हो पा रहा है, तो इस सेटिंग को चालू करने पर, SameSite की सुरक्षा में कुछ छूट पाएं प्रभावित कुकी.

• अगर सिर्फ़ SameSite=Strict कुकी ब्लॉक की जा रही हों, तो आपके पास वैल्यू को कम करने का विकल्प होता है Lax की सुरक्षा.
• ऐसे मामलों में जहां Strict और Lax, दोनों कुकी ब्लॉक की जा रही हैं और आपके कुकी एक सुरक्षित URL पर भेजी (या उससे सेट की जाती हैं) जिसे आप None को सुरक्षित रखना.
  • यह समाधान विफ़ल करेगा, यदि आप जिस URL पर कुकी भेज रहे हैं (या सेट करना असुरक्षित है. ऐसा इसलिए है, क्योंकि SameSite=None कुकी के लिए Secure एट्रिब्यूट का इस्तेमाल किया जाता है. इसका मतलब है कि हो सकता है कि वे कुकी न भेजी जाएं या किसी असुरक्षित कनेक्शन पर सेट किया गया हो. इस स्थिति में आपके पास उस कुकी का इस्तेमाल तब तक नहीं करना चाहिए, जब तक आपकी साइट एचटीटीपीएस पर अपग्रेड नहीं हो जाती.
  • याद रखें, यह सिर्फ़ कुछ समय के लिए है, क्योंकि आखिरकार तीसरे पक्ष की कुकी पूरी तरह से बंद कर दिया गया है.

अगर मैंने SameSite एट्रिब्यूट तय नहीं किया है, तो इससे मेरी कुकी पर क्या असर पड़ेगा?

जिन कुकी में SameSite एट्रिब्यूट नहीं होता उन्हें ऐसा माना जाता है जैसे उनकी पहले से तय किया गया हो SameSite=Lax. साथ ही, क्रॉस-स्कीम की यही प्रक्रिया इन कुकी पर इस तरह लागू होती है: करते हैं. ध्यान दें कि असुरक्षित तरीकों का अस्थायी अपवाद अब भी लागू होता है, ज़्यादा जानकारी के लिए, Chromium में Lax + पीओएसटी को कंट्रोल करने से जुड़ी SameSite ज़्यादा जानकारी के लिए, अक्सर पूछे जाने वाले सवाल देखें.

WebSockets कैसे प्रभावित हैं?

अगर WebSocket कनेक्शन एक जैसे हैं, तो उन्हें अब भी एक ही साइट माना जाएगा सुरक्षित रखा जाता है.

एक ही साइट:

• https:// का wss:// कनेक्शन
• http:// का ws:// कनेक्शन

क्रॉस-साइट:

• http:// का wss:// कनेक्शन
• https:// का ws:// कनेक्शन

फ़ोटो: जूलिसा कपडेविला तारीख अनस्प्लैश