HTTP कुकीज़ और सेशन

यह क्यों ज़रूरी है

Login के पीछे का लगभग हर feature इसी mechanism पर टिका है, और इसके कई defects security defects होते हैं: ऐसा session identifier जिसे scripts पढ़ सकें, जो plain HTTP पर जाए, जो logout के बाद भी काम करे या कभी expire न हो, किसी और को user बनकर काम करने देता है। इनमें से कुछ भी happy-path run में नहीं दिखता।

ये checks सस्ते और ठोस हैं: developer tools और एक test account से आप देखते हैं कि attribute है या नहीं और replay की गई request reject होती है या नहीं। Exact Set-Cookie line quote करने वाली report से developer configuration जल्दी ठीक कर सकता है।

Scope और lifetime: Domain, Path, Expires और Max-Age

Server हर Set-Cookie header में एक cookie set करता है: पहले name=value, फिर attributes। RFC 6265 तय करता है कि browser उसे कैसे store करता है और बाद की कौन-सी requests को वह मिलती है। Browser वापस सिर्फ़ name=value pairs एक Cookie header में भेजता है, इसलिए attributes response में जाँचें, request में नहीं।

• Domain: इसके बिना cookie host-only होती है और सिर्फ़ उसी host पर लौटती है जिसने उसे set किया; Domain=portal.example उसे हर subdomain, जैसे docs.portal.example, पर भी भेजता है।
• Path: cookie उन URLs पर जाती है जिनका path / की सीमा पर cookie path से शुरू होता है, इसलिए Path=/help, /help/start से match करता है, पर /helpdesk से नहीं। RFC 6265 चेतावनी देता है कि Path security boundary नहीं है।
• Expires (date) या Max-Age (seconds) cookie को persistent बनाते हैं, और दोनों हों तो Max-Age जीतता है। दोनों के बिना वह session cookie है, जो browser session ख़त्म होने पर हट जाती है। Max-Age=0 उसे delete करता है।
• Cookie की पहचान name, domain और path, तीनों से मिलकर होती है। Delete या overwrite में तीनों दोहराने होंगे; वरना पुरानी cookie बनी रहती है, और overwrite बस उसी name की एक दूसरी cookie जोड़ देता है।

Responses from https://portal.example
Set-Cookie: sid=k3Vq9XbT2mR7wLp4; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: lang=ar; Domain=portal.example; Path=/; Max-Age=31536000; Secure
Set-Cookie: tour=done; Path=/help; Expires=Fri, 01 Jan 2027 00:00:00 GMT; Secure

Request to                               Cookies the browser sends
https://portal.example/help/start        sid, lang, tour
https://portal.example/dashboard         sid, lang
https://docs.portal.example/             lang

आज़माएँ: कुकी एनालाइज़र आज़माएँ: URL पार्सर

Security attributes: Secure, HttpOnly और SameSite

ये attributes सीमित करते हैं कि cookie कैसे leak या misuse हो सकती है। हर attribute एक रास्ता बंद करता है, इसलिए जानें कि वह क्या बंद नहीं करता।

• Secure: cookie सिर्फ़ HTTPS पर भेजी जाती है, इसलिए plain HTTP traffic से पढ़ी नहीं जा सकती।
• HttpOnly: cookie document.cookie से छिपी रहती है, इसलिए injected script उसे copy नहीं कर सकता, पर browser फिर भी उसे requests के साथ भेजता है, इसलिए ऐसा script page के अंदर user बनकर काम कर सकता है।
• SameSite दूसरी site से शुरू होने वाली requests को control करता है। Strict: cookie कभी नहीं भेजी जाती, इसलिए दूसरी site के link से आया user logged out दिखता है। Lax: सिर्फ़ top-level navigations पर, यानी जब पूरा tab उस site पर जाता है (जैसे link follow करने पर), और GET जैसे safe method के साथ; cross-site form posts, images, frames या fetch calls पर नहीं। None: cross-site requests पर भी भेजी जाती है, जब तक browser settings third-party cookies block न करें, और सिर्फ़ Secure के साथ स्वीकार होती है।
• "Site" का मतलब registrable domain है, इसलिए docs.portal.example और portal.example एक ही site हैं। SameSite उन RFC 6265bis drafts से आता है जिन्हें browsers implement करते हैं, RFC 6265 से नहीं, और browsers के defaults अलग हैं, इसलिए उम्मीद रखें कि इसे explicit set किया जाए।
• Session cookie का baseline: Secure, HttpOnly, explicit SameSite=Lax या Strict, कोई Domain नहीं जब तक subdomains को ज़रूरत न हो, और कोई Expires या Max-Age नहीं, क्योंकि OWASP Session Management Cheat Sheet non-persistent session cookies की सलाह देती है।

आज़माएँ: कुकी एनालाइज़र आज़माएँ: HTTP हेडर पार्सर

Server-side sessions: identifier, expiry और logout

Login पर server session record (user, roles, समय) को memory, database या cache जैसे session store में रखता है और Set-Cookie में सिर्फ़ एक random identifier भेजता है। बाद की हर request पर वह identifier ढूँढता है: live session मिले तो request उसी user के रूप में चलती है; वरना page login page पर redirect होता है और API 401 Unauthorized लौटाता है।

यानी दो घड़ियाँ हैं, browser में cookie की और server पर session की, और सुरक्षा सिर्फ़ server की घड़ी देती है, क्योंकि identifier रखने वाला कोई भी उसे भेजता रह सकता है। OWASP Session Management Cheat Sheet ये माँगती है:

• Cryptographically secure random generator से बना identifier, कम से कम 64 bits entropy (उसे guess करना कितना मुश्किल है, इसका माप) वाला, और user id या timestamp जैसे किसी मतलब के बिना।
• Login पर और privilege के हर बदलाव पर नया identifier, और पुराना invalid; वरना login से पहले plant किया गया identifier (session fixation) बाद में भी काम करता है।
• आख़िरी request से गिना जाने वाला idle timeout और login से गिना जाने वाला absolute timeout, दोनों server पर लागू।
• ऐसा logout जो server पर record ख़त्म करे; Max-Age=0 से cookie delete करना सिर्फ़ browser को साफ़ करता है।
• Identifier सिर्फ़ cookie में, URL में कभी नहीं, जहाँ से वह history, logs और Referer headers में leak होता है।

Worked example: login session को trace और टेस्ट करना

Test environment में एक staff portal, https://portal.example, की requirement है: "15 मिनट तक कोई activity न हो तो session ख़त्म होता है, और login के 8 घंटे बाद भी। Log out से session ख़त्म होता है।" Test account और खुले Network panel के साथ tester login करता है, dashboard खोलता है, logout करता है और नीचे वाला exchange record करता है।

सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की अनुमति है, और reports में session identifiers mask करें, क्योंकि copy किया गया live identifier password की तरह काम करता है। हर check एक test case बनता है:

• Attributes: sid में Secure, HttpOnly और SameSite=Lax हैं, और कोई Domain या Max-Age नहीं।
• Renewal: site ने login से पहले ही anonymous visitor को एक session दिया था (Ae5f…); वह value नई value से अलग है, और उसके साथ भेजी गई request login page पर पहुँचती है।
• Logout: delete वही Path=/ दोहराता है, और curl से पुरानी value replay करने पर (-i response headers print करता है, -H request header जोड़ता है), जैसे curl -i -H "Cookie: sid=k3Vq9XbT2mR7wLp4" https://portal.example/dashboard, /login पर redirect मिलता है, dashboard data कभी नहीं।
• Boundary पर idle timeout: network delay और server का timer ठीक-ठीक second को भरोसेमंद नहीं रहने देते, इसलिए एक छोटा margin तय करें और boundary के दोनों तरफ़ टेस्ट करें, जैसे 14 मिनट 50 सेकंड idle के बाद की request (अब भी काम करती है) और 15 मिनट 10 सेकंड के बाद वाली (login page)। पूछें कि क्या test environment में छोटे timeouts इस्तेमाल हो सकते हैं।
• Absolute timeout: लगातार activity के बावजूद session login के 8 घंटे बाद ख़त्म होता है।
• Scope: docs.portal.example को sid कभी नहीं मिलता।

POST /login HTTP/1.1
Host: portal.example
Cookie: sid=Ae5fUq0Zr8Ty2Nc6

HTTP/1.1 303 See Other
Location: /dashboard
Set-Cookie: sid=k3Vq9XbT2mR7wLp4; Path=/; Secure; HttpOnly; SameSite=Lax

GET /dashboard HTTP/1.1
Host: portal.example
Cookie: sid=k3Vq9XbT2mR7wLp4

POST /logout HTTP/1.1
Host: portal.example
Cookie: sid=k3Vq9XbT2mR7wLp4

HTTP/1.1 303 See Other
Location: /login
Set-Cookie: sid=; Path=/; Max-Age=0; Secure; HttpOnly; SameSite=Lax

आज़माएँ: कुकी एनालाइज़र आज़माएँ: cURL जनरेटर

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

संदर्भ

• RFC 6265: HTTP State Management MechanismIETF · 2011कुकी कैसे सेट और भेजी जाती हैं: Set-Cookie के एट्रिब्यूट (Expires, Max-Age, Domain, Path, Secure, HttpOnly) और उनके स्कोप नियम।
• OWASP Cheat Sheet Series: Session ManagementOWASP Foundationसेशन आइडेंटिफ़ायर की एंट्रॉपी, कुकी एट्रिब्यूट, एक्सपायरी, लॉगिन के बाद नवीनीकरण और लॉगआउट हैंडलिंग।
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)कुकी की अवधि, स्कोप, Secure/HttpOnly/SameSite एट्रिब्यूट और उनके सुरक्षा निहितार्थ।
• OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionOWASP FoundationCSRF से बचाव: सिंक्रोनाइज़र टोकन, SameSite कुकी और ऑरिजिन जाँच।