Set-Cookie के कौन-से attributes सेशन कुकी की रक्षा करते हैं?
Secure कुकी को सादे HTTP से दूर रखता है, HttpOnly उसे JavaScript से छिपाता है ताकि XSS की कोई गलती उसे पढ़ न सके, और SameSite (Lax या Strict) ब्राउज़र को उसे दूसरी साइटों की शुरू की गई रिक्वेस्ट के साथ भेजने से रोकता है। नाम में __Host- प्रीफ़िक्स ब्राउज़र से Secure, Path=/ और Domain न होना लागू करवाता है, और छोटी Max-Age चोरी हुई वैल्यू के काम आने का समय घटाती है; RFC 6265bis ये नियम और नियम तोड़ने वाली कुकी को ब्राउज़र कब ठुकराता है, यह तय करता है।
सुरक्षा नोट: सेशन वाली कुकी जब तक ज़िंदा है, पासवर्ड ही है। प्रोडक्शन की सेशन कुकी टिकट या चैट में कभी पेस्ट न करें; अगर कोई खुल गई हो तो वह सेशन सर्वर पर ख़त्म करें।
कुकी सिक्योरिटी एनालाइज़र कैसे इस्तेमाल करें
- पेज का URL डालें, या ब्राउज़र के डेवलपर टूल से Set-Cookie हेडर पेस्ट करें (Network टैब → कुकी सेट करने वाली रिक्वेस्ट → Response Headers)।
- जिस पेज पर आप पहुँचते हैं उसे जाँचने के लिए "रीडायरेक्ट फॉलो करें" चालू रखें; अगर आपकी ज़रूरी कुकी किसी रीडायरेक्ट पर सेट होती है, जैसे लॉग-इन फ़ॉर्म के जवाब में, तो इसे बंद कर दें।
- "कुकी जाँचें" दबाएँ, ग्रेड और उसकी वजह पढ़ें, फिर नतीजों को High से Info तक क्रम से देखें।
- कुकी टेबल में attributes को साथ-साथ मिलाएँ, और किसी भी टेबल को टिकट या ऑडिट रिपोर्ट के लिए CSV में डाउनलोड करें।
कुकी सिक्योरिटी एनालाइज़र की खूबियाँ
- Mutqan सर्वर के ज़रिए किसी लाइव पेज के Set-Cookie हेडर पढ़ता है, या डेवलपर टूल या curl -I से पेस्ट की गई सूची — पेस्ट में मौजूद बाक़ी रिस्पॉन्स हेडर छोड़ दिए जाते हैं
- हर कुकी को RFC 6265bis से जाँचता है: Secure, HttpOnly, SameSite, __Host- और __Secure- प्रीफ़िक्स, Domain और Path का दायरा, Max-Age और Expires, और 4096 बाइट व 400 दिन की सीमाएँ
- बताता है कि हर समस्या पर ब्राउज़र असल में क्या करता है — कुकी ठुकराता है, attribute अनदेखा करता है या उसकी उम्र छोटी करता है — और उसे ठीक करने वाला बदलाव भी
- सेशन, लॉग-इन और CSRF कुकी को नाम से पहचानकर उन पर सख़्त पैमाना लगाता है; स्क्रिप्ट द्वारा पढ़े जाने वाले CSRF टोकन में HttpOnly न होना गलती नहीं माना जाता
- पेज को A से F तक ग्रेड देता है, ऐसी सीमाओं के साथ कि एक खुली सेशन कुकी दर्जनों हानिरहित एनालिटिक्स कुकी के पीछे न छिप सके
- दिखाने या एक्सपोर्ट करने से पहले हर वैल्यू छिपा देता है: सेशन id सिर्फ़ अपने पहले और आख़िरी अक्षरों में दिखती है
- डिलीट करने वाले हेडर (Max-Age=0 या बीती हुई Expires) अलग से देखता है: सिर्फ़ वे Domain और Path जाँचे जाते हैं जिनसे डिलीट काम करे, ग्रेड में उन्हें नहीं गिना जाता
इनपुट और आउटपुट
इनपुट
- पेज URL — http:// या https:// एड्रेस; example.com जैसा सिर्फ़ होस्ट https:// माना जाता है। Mutqan सर्वर बिना कुकी के एक GET रिक्वेस्ट भेजता है, ऐसे तय हेडर के साथ जो Mutqan रिले की पहचान बताते हैं (User-Agent MutqanTools-Relay/1.0)।
- रीडायरेक्ट फॉलो करें — डिफ़ॉल्ट रूप से चालू (5 हॉप तक); पहले जवाब की कुकी देखने के लिए बंद करें।
- पेस्ट किए हेडर — Set-Cookie लाइनें, "Set-Cookie:" के साथ या बिना, 500 लाइनों तक; स्टेटस लाइन और दूसरे हेडर छोड़ दिए जाते हैं। पेस्ट होने पर कुछ भी फ़ेच नहीं होता और URL सिर्फ़ पेज का होस्ट और स्कीम बताता है।
आउटपुट
- सारांश — ग्रेड और स्कोर, कुकी की संख्या, कितनी में Secure और HttpOnly है, कितनी SameSite=None इस्तेमाल करती हैं और कितने हेडर सिर्फ़ कुकी डिलीट करते हैं।
- नतीजे — हर समस्या उसके स्तर, उससे जुड़ी कुकी और उसे ठीक करने वाले बदलाव के साथ, सबसे गंभीर पहले।
- कुकी — हर Set-Cookie हेडर की एक पंक्ति: छिपी वैल्यू, Secure, HttpOnly, SameSite, दायरा, पाथ, दिनों में उम्र, बाइट में साइज़ और समस्याओं की संख्या।
- ग्रेड की वजह और फ़ेच विवरण — वह सीमा जिसने ग्रेड तय किया; फ़ेच किए पेज के लिए आख़िरी URL, स्टेटस, फ़ॉलो किए रीडायरेक्ट, होस्ट का resolve हुआ एड्रेस और फ़ेच का समय।
कुकी सिक्योरिटी एनालाइज़र का उदाहरण
लॉग-इन रिस्पॉन्स से पेस्ट की गई पाँच कुकी
इनपुट:
Page URL: https://www.example.com/
Set-Cookie: sessionid=8f2c41d9a7e34b05b1c6e2f09d3a7c18; Path=/; HttpOnly
Set-Cookie: csrftoken=Zq81LmP0aXv3; Path=/; Secure; SameSite=Lax; Max-Age=31449600
Set-Cookie: __Host-prefs=lang%3Den; Path=/; Secure; SameSite=Strict
Set-Cookie: _ga=GA1.1.1234567890.1760000000; Domain=.example.com; Path=/; Max-Age=63072000; SameSite=Lax
Set-Cookie: tracking=abc; SameSite=None; Path=/आउटपुट:
ग्रेड D (81/100) — D पर सीमित: सेशन जैसी एक कुकी में High स्तर की समस्या है
कुकी 5 · Secure के साथ 2/5 · HttpOnly के साथ 1/5 · SameSite=None 1
High · sessionid · Secure नहीं है
High · tracking · Secure के बिना SameSite=None — ठुकराई गई
Medium · sessionid · SameSite attribute नहीं है
Medium · _ga, tracking · Secure नहीं है
Low · _ga · Domain कुकी को हर सबडोमेन से साझा करता है · 400 दिन से लंबी उम्र
Info · csrftoken · __Host- प्रीफ़िक्स के योग्य
sessionid की वैल्यू ऐसे दिखती है: 8f2…c18कुकी सिक्योरिटी एनालाइज़र के नतीजे कैसे पढ़ें
High का मतलब है कि ब्राउज़र कुकी ठुकरा देगा या कोई सेशन कुकी खुली है (Secure नहीं, HttpOnly नहीं, गलत प्रीफ़िक्स, public suffix वाला Domain) — इन्हें पहले ठीक करें। Medium सुरक्षा कमज़ोर करता है (SameSite नहीं, क्रॉस-साइट भेजी जाने वाली सेशन कुकी, लंबी उम्र वाला सेशन)। Low और Info साफ़-सफ़ाई और सुझाव हैं।
A ग्रेड का मतलब है कि हेडर जितना दिखा सकता है, उसमें हर लाइव कुकी अच्छे तरीक़ों के क़रीब है। इससे यह पता नहीं चलता कि सर्वर सेशन कैसे बनाता, बदलता या ख़त्म करता है।
नतीजे में "ठुकराई गई" का मतलब है कि ब्राउज़र कुकी को बिल्कुल सेव नहीं करता: उस पर टिका काम उस ब्राउज़र में पहले से टूटा है, चाहे साइट किसी दूसरे ब्राउज़र में ठीक लगे।
फ़ेच किए पेज पर "कोई Set-Cookie हेडर नहीं" आम बात है: कई साइट लॉग-इन के बाद, सहमति के बाद या JavaScript से ही कुकी सेट करती हैं। जिस कुकी की परवाह है, उसे सेट करने वाला जवाब जाँचें।
SameSite के बिना कुकी को Chromium आधारित ब्राउज़र Lax मानते हैं, जबकि Safari और Firefox कुछ हालात में उसे अब भी क्रॉस-साइट भेजते हैं, इसलिए उसका बर्ताव ब्राउज़र के हिसाब से बदलता है; attribute साफ़ लिख देने से यह दुविधा ख़त्म होती है।
कुकी सिक्योरिटी एनालाइज़र कब इस्तेमाल करें
- रिलीज़ से पहले जाँचना कि नया लॉग-इन फ़्लो सेशन कुकी को Secure, HttpOnly और SameSite के साथ सेट करता है।
- एनालिटिक्स और विज्ञापन कुकी में Secure के बिना SameSite=None ढूँढना, जिन्हें ब्राउज़र चुपचाप हटा देते हैं।
- पेनिट्रेशन टेस्ट या ऑडिट का ऐसा नतीजा लिखना जिसमें कमी वाला attribute और उसे ज़रूरी बनाने वाला नियम दोनों हों।
- पक्का करना कि लॉग-आउट का जवाब सेशन कुकी को सच में डिलीट करता है, मूल कुकी से मेल खाते Domain और Path के साथ।
समस्या निवारण
- "पेस्ट किए टेक्स्ट में कोई Set-Cookie हेडर नहीं मिला": कुकी सेट करने वाली रिक्वेस्ट के रिस्पॉन्स हेडर कॉपी करें, रिक्वेस्ट हेडर नहीं। DevTools में रिक्वेस्ट चुनें, Headers खोलें और Response Headers वाला हिस्सा कॉपी करें।
- फ़ेच किए पेज पर कोई कुकी नहीं, जबकि ब्राउज़र में हैं: हो सकता है वे JavaScript से लिखी गई हों, पेज की किसी दूसरी रिक्वेस्ट से आई हों, सहमति बैनर के बाद या सिर्फ़ लॉग-इन यूज़र के लिए सेट होती हों। उस जवाब के हेडर पेस्ट करें।
- "Mutqan सर्वर इस एड्रेस तक नहीं पहुँच सकता": होस्ट किसी प्राइवेट या आरक्षित एड्रेस पर resolve होता है, या सर्वर के सुरक्षा नियम उसे रोकते हैं। अंदरूनी साइट को उसके हेडर पेस्ट करके फिर भी जाँचा जा सकता है।
- पेस्ट मोड में Domain-match और HTTP पर Secure वाली जाँच नहीं दिख रहीं: पेज का URL भी डालें। वह सिर्फ़ संदर्भ के लिए है, कुछ फ़ेच नहीं होता।
कुकी सिक्योरिटी एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल
मेरी कुकी "ठुकराई गई" क्यों दिख रही है?
क्योंकि ब्राउज़र उसे सेव ही नहीं करेगा: Secure के बिना SameSite=None, __Host- या __Secure- प्रीफ़िक्स जिसके नियम पूरे नहीं, ऐसा Domain जो पेज के होस्ट को कवर नहीं करता या public suffix है, Secure के बिना Partitioned कुकी, या 4096 बाइट से बड़ा नाम और वैल्यू। नतीजे में टूटा नियम लिखा होता है; उसे ठीक करने तक उस ब्राउज़र में इस कुकी पर टिका काम नहीं चलेगा।
टूल कैसे तय करता है कि कोई कुकी सेशन कुकी है?
नाम से: अगर नाम में session, sid, auth, token, jwt, login, remember, refresh या csrf जैसा शब्द पूरे हिस्से के रूप में हो — JSESSIONID, PHPSESSID, connect.sid या laravel_session जैसे जुड़े नाम भी। इन पर सख़्त पैमाना लगता है क्योंकि इनके खुलने से अकाउंट ही खुल जाता है। नाम सिर्फ़ एक संकेत है, टूल की ख़ातिर अपनी कुकी के नाम न बदलें।
क्या CSRF टोकन वाली कुकी में HttpOnly ज़रूरी है?
नहीं, अगर आपका फ़्रंट-एंड उसे पढ़कर हेडर में वापस भेजता है (double-submit पैटर्न); इसीलिए HttpOnly न होना यहाँ गलती नहीं, Info के रूप में दिखता है। अगर टोकन की तुलना सिर्फ़ सर्वर करता है, तो HttpOnly जोड़ दें।
मेरे ब्राउज़र में बहुत कुकी हैं, फिर पेज जाँचने पर कोई क्यों नहीं दिखी?
Mutqan सर्वर बिना कुकी और बिना लॉग-इन के सिर्फ़ एक रिक्वेस्ट भेजता है। JavaScript से लिखी कुकी, पेज की दूसरी रिक्वेस्ट से आई कुकी, सहमति बैनर के बाद या लॉग-इन के बाद सेट होने वाली कुकी उस जवाब में नहीं आतीं। जिस जवाब की कुकी चाहिए, उसके Set-Cookie हेडर डेवलपर टूल से कॉपी करके यहाँ पेस्ट करें।
क्या मेरी कुकी की वैल्यू कहीं भेजी या सेव की जाती हैं?
पेस्ट मोड में पूरा विश्लेषण आपके ब्राउज़र में ही होता है। URL मोड में सर्वर पेज लाकर उसके हेडर आपके ब्राउज़र को लौटा देता है, कुछ सेव नहीं करता। दोनों में वैल्यू दिखाने या एक्सपोर्ट करने से पहले छिपा दी जाती हैं।
"__Host- प्रीफ़िक्स के योग्य" का क्या मतलब है?
कुकी में पहले से Secure और Path=/ है और Domain नहीं है। उसका नाम __Host-name करने पर ब्राउज़र इन नियमों को लागू करेगा, ताकि कोई सबडोमेन या सादा HTTP जवाब उसे कभी बदल न सके। यह सुझाव है, कोई कमी नहीं।
तकनीकी नोट्स
पार्सिंग RFC 6265bis (draft-ietf-httpbis-rfc6265bis, RFC 6265 का वह संशोधन जिसे ब्राउज़र लागू करते हैं) के अनुसार है: attribute के नाम case-insensitive हैं, किसी attribute की आख़िरी मौजूदगी मान्य होती है, Expires को सामान्य डेट पार्सर से नहीं बल्कि RFC 6265 §5.1.1 के cookie-date एल्गोरिदम से पढ़ा जाता है, और Max-Age को Expires पर प्राथमिकता मिलती है।
लागू किए गए ब्राउज़र नियम: http:// पेज से Secure कुकी सेट नहीं हो सकती; SameSite=None के लिए Secure ज़रूरी है; __Secure- के लिए Secure, और __Host- के लिए साथ में Path=/ और Domain का न होना (प्रीफ़िक्स case-insensitive मिलाए जाते हैं); Domain को पेज के होस्ट से domain-match करना चाहिए और वह public suffix नहीं हो सकता (साथ जुड़ी Public Suffix List से जाँचा जाता है); 4096 बाइट से बड़े नाम और वैल्यू वाली कुकी ठुकराई जाती है और 1024 बाइट से बड़ी attribute वैल्यू अनदेखी होती है; उम्र 400 दिन पर रोक दी जाती है; Partitioned (CHIPS) कुकी का Secure होना ज़रूरी है।
स्कोर: हर लाइव कुकी 100 से शुरू होती है और हर High समस्या पर 25, Medium पर 10 और Low पर 3 अंक खोती है; पेज का स्कोर इनका औसत है, जिसमें से हर दोहराए नाम पर 5 और एक डोमेन पर 50 से ज़्यादा कुकी होने पर 10 घटते हैं। A = 90 या ज़्यादा, B = 75, C = 60, D = 40, F उससे नीचे। सीमाएँ: सेशन जैसी कुकी में Secure और HttpOnly दोनों न हों तो F; सेशन कुकी HTTP पर सेट हों या किसी सेशन कुकी में High समस्या हो तो D; किसी भी कुकी में High समस्या हो तो C।
सेशन जैसे नाम शब्द-दर-शब्द पहचाने जाते हैं (sid, session, auth, token, jwt, login, remember, refresh, csrf, xsrf और JSESSIONID, PHPSESSID या connect.sid जैसे जुड़े रूप), इसलिए sidebar_state या device_id जैसे नाम सेशन कुकी नहीं माने जाते।
सीमाएँ और कार्यप्रणाली
सिर्फ़ HTTP रिस्पॉन्स हेडर से सेट होने वाली कुकी दिखती हैं। JavaScript से लिखी, पेज की दूसरी रिक्वेस्ट (स्क्रिप्ट, इमेज, API कॉल) से आई या थर्ड-पार्टी फ़्रेम की कुकी पेज की एक रिक्वेस्ट में नहीं दिखतीं।
रिक्वेस्ट Cloudflare के नेटवर्क पर चल रहे Mutqan सर्वर से, पहली बार आए विज़िटर की तरह, बिना कुकी और बिना लॉग-इन जाती है। असली ब्राउज़र, किसी इलाक़े, लॉग-इन यूज़र या सहमति के बाद साइट अलग कुकी सेट कर सकती है, और कुछ साइट ऑटोमेटेड रिक्वेस्ट को चुनौती देती हैं।
रीडायरेक्ट फ़ॉलो करने पर बीच के जवाबों की कुकी वापस नहीं आतीं; पहला जवाब पढ़ने के लिए "रीडायरेक्ट फॉलो करें" बंद करें।
ग्रेड सिर्फ़ उतना ही बताता है जितना हेडर दिखा सकता है। सेशन फ़िक्सेशन, टोकन की रैंडमनेस, सर्वर पर सेशन की समाप्ति और CSRF सुरक्षा कुकी attributes से नहीं जाँची जा सकतीं।
सुरक्षा और गोपनीयता
URL मोड में URL Mutqan सर्वर को जाता है, जो उस पेज पर एक GET रिक्वेस्ट भेजकर उसके रिस्पॉन्स हेडर आपके ब्राउज़र को लौटाता है; कुछ भी सेव नहीं होता। पेस्ट मोड में हेडर आपके ब्राउज़र से बाहर नहीं जाते।
पेस्ट किए हेडर में लाइव सेशन id हो सकती हैं। वैल्यू दिखाने और एक्सपोर्ट से पहले छिपा दी जाती हैं, फिर भी पेस्ट किए टेक्स्ट को गोपनीय मानें, और अगर वह प्रोडक्शन का था तो लॉग-आउट करें या सेशन बदल दें।
संदर्भ
- Cookies: HTTP State Management Mechanism (draft-ietf-httpbis-rfc6265bis)RFC 6265 का वह संशोधन जिसे ब्राउज़र लागू करते हैं: SameSite, __Host- और __Secure- प्रीफ़िक्स, 400 दिन की उम्र-सीमा, साइज़ की सीमाएँ और कुकी कब ठुकराई जाती है।
- RFC 6265: HTTP State Management Mechanismकुकी कैसे सेट और भेजी जाती हैं: Set-Cookie के एट्रिब्यूट (Expires, Max-Age, Domain, Path, Secure, HttpOnly) और उनके स्कोप नियम।
- Set-Cookie header — MDNSet-Cookie का हर attribute और ब्राउज़र में उसका सपोर्ट, Partitioned (CHIPS) और कुकी प्रीफ़िक्स समेत।