मॉड्यूल 12 · वेब एप्लिकेशन टेस्टिंग

कुकीज़ और वेब स्टोरेज

Mutqan Soft QA टीम द्वारा · · 19 मिनट · शुरुआती

एक web application आपके browser में तीन आम जगहों पर data रख सकती है। Cookies छोटे name–value pairs हैं जिन्हें server Set-Cookie response header से set करता है और browser Cookie request header में वापस भेजता है। Local storage और session storage, जिन्हें मिलाकर web storage कहते हैं, key–value stores हैं जिन्हें सिर्फ़ page की JavaScript पढ़ती और लिखती है; इनमें से कुछ भी server तक तब तक नहीं पहुँचता जब तक कोई script उसे न भेजे।

उदाहरण के लिए, एक shop तीनों इस्तेमाल कर सकती है: एक cookie आपको logged in रखती है, local storage browser बंद करने के बाद भी आपका cart रखता है, और session storage एक tab का checkout step रखता है। Browser DevTools वाले lesson में आपने इन्हें Application panel में देखा था; यहाँ आप वे नियम सीखेंगे जो तय करते हैं कि reload, नए tab, restart और logout के बाद क्या बचता है, ताकि test करने से पहले ही result का अनुमान लगा सकें।

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

इस area के defects गलत data के बचे रहने या सही data के गायब होने के बारे में होते हैं: logout के बाद भी logged in user, refresh पर खाली होता cart, दूसरे tab में टूटता checkout, या shared computer पर पिछले user का address। ये happy-path run में शायद ही दिखते हैं, क्योंकि कोई tab बंद नहीं करता, browser restart नहीं करता या account नहीं बदलता।

Browser storage security और privacy का भी मामला है। HttpOnly के बिना session cookie को page की कोई भी script पढ़ सकती है, local storage में रखा token user के जाने के बाद भी device पर रहता है, और browser में रखा personal data अपने मकसद से ज़्यादा समय तक बचा रह सकता है। हर mechanism का व्यवहार जानने से ये risks planned tests में बदल जाते हैं।

Browser की नज़र से cookies

RFC 6265 बताता है कि cookies कैसे काम करती हैं। Browser हर स्वीकार की गई cookie store करता है और उसे उन अगली requests के साथ जोड़ता है जिनका host और path match करे, जब तक cookie expire न हो। Attributes तय करते हैं कि cookie कहाँ जाएगी और कितने समय तक रहेगी, इसलिए इन्हीं को test किया जाता है।

नीचे के sample में sid की कोई expiry नहीं, इसलिए वह session cookie है; lang एक साल (31,536,000 seconds) के लिए persistent है। अगली requests में browser सिर्फ़ name=value pairs भेजता है, attributes कभी नहीं, इसलिए attributes response में या Application panel में जाँचे जाते हैं।

  • Expires (एक date) या Max-Age (seconds) cookie को persistent बनाता है; दोनों हों तो Max-Age लागू होता है। दोनों न हों तो वह session cookie है, जो browser session ख़त्म होने पर हट जाती है।
  • Domain और Path तय करते हैं कि कौन-से hosts और URLs उसे पाएँगे। Domain के बिना सिर्फ़ वही exact host उसे पाता है जिसने उसे set किया।
  • Secure उसे सिर्फ़ HTTPS पर भेजता है; HttpOnly उसे JavaScript से छिपाता है, इसलिए document.cookie में वह नहीं दिखती।
  • SameSite (Strict, Lax या None) RFC 6265 से नया है, पर आज के browsers इसे support करते हैं; यह तय करता है कि दूसरी sites से शुरू हुई requests के साथ cookie जाए या नहीं। None के साथ Secure ज़रूरी है; जाँचें कि application यह value साफ़ तौर पर set करती है और browser के default पर निर्भर नहीं रहती।
  • RFC 6265 browsers से कम से कम 4096 bytes प्रति cookie और 50 cookies प्रति domain support करने को कहता है। हर matching request cookies साथ ले जाती है, इसलिए बड़ी cookies हर request में bytes जोड़ती हैं, और headers बहुत बड़े हो जाएँ तो server request reject कर सकता है।
HTTP/1.1 200 OK
Set-Cookie: sid=Yx81Tq0bA2; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: lang=ar; Max-Age=31536000; Path=/; Secure; SameSite=Lax

GET /account HTTP/1.1
Host: shop.example
Cookie: sid=Yx81Tq0bA2; lang=ar

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

Browser session कैसे बनाए रखता है

HTTP stateless है: हर request अपने आप में अलग है। आपको logged in रखने के लिए server login पर एक session बनाता है, उसका data server पर रखता है और browser को सिर्फ़ एक random session identifier देता है, आम तौर पर sid जैसी cookie में। Browser उसे हर request के साथ भेजता है और server session ढूँढ लेता है। Browser के पास चाबी होती है, session नहीं।

कुछ single-page applications इसकी जगह एक token लेती हैं, अक्सर JWT (JSON Web Token: एक signed string जिसमें user और expiry time जैसी जानकारी होती है), उसे web storage या memory में रखती हैं और खुद Authorization header में जोड़ती हैं। Page की कोई भी script web storage पढ़ सकती है, इसीलिए OWASP session identifiers या tokens वहाँ न रखने की सलाह देता है; HttpOnly cookie scripts की पहुँच से बाहर है। दोनों हालात में वही session checks लागू होते हैं:

  • Login: login पर session identifier बदलता है, ताकि login से पहले डाली गई value बाद में किसी काम की न रहे।
  • Logout: server session को invalidate करता है। Cookie हटाना काफ़ी नहीं; पुराने identifier के साथ दोबारा भेजी गई request reject होनी चाहिए।
  • Timeouts: तय idle time और absolute time के बाद session ख़त्म होता है, और user साफ़ message के साथ login page पर पहुँचता है, error पर नहीं।
  • Tabs: session cookie हर tab में shared होती है, इसलिए एक tab में logout के बाद बाकी tabs को अपने अगले action पर login page दिखाना चाहिए।

आज़माएँ: JWT डिकोडर

Local storage और session storage

Web storage HTML Standard में परिभाषित है। दोनों stores string keys और string values रखते हैं, origin (scheme, host और port) के हिसाब से अलग होते हैं, इसलिए site के http और https versions data share नहीं करते, और सिर्फ़ JavaScript से इस्तेमाल होते हैं, जैसे localStorage.setItem('cart', value)। कुछ भी अपने आप server को नहीं भेजा जाता। दोनों का फ़र्क lifetime और sharing में है:

  • Local storage उसी origin के हर tab में shared है और उसकी कोई expiry नहीं: browser restart के बाद भी रहता है, जब तक कोई script, user या browser उसे clear न करे।
  • Session storage एक tab का होता है। Reload के बाद बचता है और tab बंद होने पर clear हो जाता है; नए tab को अपना अलग store मिलता है, जबकि tab duplicate करने पर वह copy हो जाता है।
  • Values सिर्फ़ strings होती हैं। पहले JSON.stringify से text में बदले बिना save किया गया object [object Object] बन जाता है, यह defect आप Application panel में देख सकते हैं।
  • हर origin की जगह सीमित है, आम तौर पर browser के हिसाब से कुछ megabytes। भर जाने पर setItem error throw करता है, जिसे application को handle करना चाहिए।
  • Private window को अलग storage मिलता है, जिसे private session ख़त्म होने पर browser मिटा देता है।
Cookie हर matching request के साथ server तक जाती है और HttpOnly से scripts से छिप सकती है; local storage tabs और restarts के पार browser में रहता है, session storage एक ही tab में उसके बंद होने तक।

CookieRFC 6265

Server Set-Cookie से set करता है, या script, अगर वह HttpOnly न हो

Server को भेजा जाता है:
अपने आप, हर matching request के साथ
किनके बीच shared:
Browser के सभी tabs
Lifetime:
Expires या Max-Age तक; इनके बिना browser session ख़त्म होने तक
Page scripts पढ़ सकती हैं:
HttpOnly हो तो नहीं
पहला check:
Logout के बाद server पुरानी session value reject करे

Local storagelocalStorage

Page की JavaScript द्वारा लिखी string keys और values

Server को भेजा जाता है:
कभी अपने आप नहीं
किनके बीच shared:
उसी origin के सभी tabs
Lifetime:
कोई expiry नहीं: जब तक script, user या browser clear न करे
Page scripts पढ़ सकती हैं:
हमेशा
पहला check:
User B को user A का छोड़ा हुआ कभी न दिखे

Session storagesessionStorage

वही interface, पर सिर्फ़ एक tab के लिए

Server को भेजा जाता है:
कभी अपने आप नहीं
किनके बीच shared:
सिर्फ़ एक tab; tab duplicate करने पर copy होता है
Lifetime:
Tab बंद होने तक; reload के बाद बचा रहता है
Page scripts पढ़ सकती हैं:
हमेशा
पहला check:
नया tab पुराने tab के step के बिना शुरू हो

दिखाई गई lifetimes default हैं: जो browser start होने पर पिछला session restore करता है, वह session cookies और session storage भी restore करता है।

Worked example: login, cart और checkout

एक shop sid को session cookie के रूप में set करती है, remember को 30 दिन की cookie के रूप में सिर्फ़ तब set करती है जब user "Remember me" चुने, cart local storage में और checkout step session storage में रखती है। Test से पहले tester ऊपर के नियमों से हर result का अनुमान लगाता है, फिर उसे page और Application panel में जाँचता है। Table मानती है कि user ने "Remember me" चुना है; हर cell एक expected result है, और हर row एक test case बनती है।

"Remember me" के बिना browser दोबारा खोलने पर फिर से login करना पड़ता है और cart बना रहता है; उसके साथ shop remember के ज़रिए नया sid जारी करती है, और remember को 30 दिन बाद काम करना बंद कर देना चाहिए। Logout के बाद cart बचे या नहीं, यह product का फ़ैसला है, tester का नहीं: इसे सवाल के रूप में उठाएँ और जवाब test case में दर्ज करें।

Action                         sid       remember   cart (local)   step (session)
Reload the page                kept      kept       kept           kept
Open the shop in a new tab     sent      sent       same cart      empty
Close and reopen the browser   gone (1)  kept       kept           gone (1)
Log out                        deleted   deleted    decide (2)     gone
Clear site data                gone      gone       gone           gone

Old sid replayed after logout  -> login page or 401, never account data
Shop after clearing site data  -> loads logged out, empty cart, no error
(1) unless the browser restores the previous session on start-up
(2) product decision: on a shared computer the next user sees the cart

Persistence, clearing और privacy की testing

Test account इस्तेमाल करें, और stored data सिर्फ़ उन्हीं systems पर edit या clear करें जिन्हें test करने की आपको अनुमति है। नीचे के पाँच areas cover करें; list के बाद की Console lines दिखाती हैं कि web storage सीधे कैसे पढ़ें और बदलें।

  • Persistence: reload, नया tab, duplicate tab, browser restart और expiry का पल, हर result को requirement से मिलाकर।
  • Clearing: एक cookie या key delete करें, फिर पूरा site data clear करें। Application को साफ़ शुरू होना चाहिए, blank page या script error के बिना।
  • पुरानी और corrupted values: invalid या पुराने format वाली value, जैसी format बदलने वाली release के बाद मिलती है, लौटकर आने वाले users के लिए कुछ नहीं तोड़नी चाहिए।
  • Shared computer: user A से login करें, logout करें, फिर user B से login करें। B को A का कुछ भी नहीं दिखना चाहिए — नाम, address, cart, searches, drafts।
  • Privacy: passwords और card numbers की cookies या web storage में कोई जगह नहीं, बाकी personal data सिर्फ़ तब तक जब तक किसी feature को उसकी ज़रूरत हो, और session cookies पर Secure और HttpOnly हों। अगर site cookie consent माँगती है, तो non-essential cookies reject करें और Application panel में पक्का करें कि उनमें से कोई set नहीं हुई।
localStorage.getItem('cart')          // read what the shop stored
localStorage.setItem('cart', '{bad')  // invalid JSON: reload, does the page recover?
sessionStorage.clear()                // empty this tab's session storage
document.cookie                       // HttpOnly cookies are not listed

आम गलतियाँ

  • सिर्फ़ एक लंबे समय से खुले tab में test करना, जिससे नए tab, restart और logout का व्यवहार कभी दिखता ही नहीं।
  • Cookie गायब हो गई, इसलिए logout को pass मान लेना, यह जाँचे बिना कि server पुराना session identifier reject करता है।
  • यह मान लेना कि session storage session cookie जैसा व्यवहार करता है: cookie हर tab में shared है और server तक जाती है, session storage एक tab का है और browser में ही रहता है।
  • Restart के बाद बची session cookie को defect के रूप में report करना, यह जाँचे बिना कि browser start होने पर पिछला session restore करता है या नहीं।
  • सिर्फ़ साफ़, बिना पुराने data वाले browser से test करना, जिससे पुरानी cookies या पुराने storage format वाले लौटते users कभी simulate नहीं होते।
  • Bug report में cookie values, tokens या personal data वाला storage content mask किए बिना paste करना।

QA का नज़रिया

जल्दी पूछें कि feature browser में क्या रखता है, कहाँ और कितने समय तक। एक छोटी table, जिसमें name, mechanism, attributes, lifetime और logout पर क्या होता है लिखा हो, ऐसा test basis है जिसे developers, product owner और security reviewers सब जाँच सकते हैं। "क्या cart logout के बाद बचना चाहिए?" या "Remember me कितने दिन चलता है?" जैसे खुले सवाल requirement के सवाल हैं, tester के फ़ैसले नहीं।

Bug report में exact cookie या key का नाम, Application panel में दिखे उसके attributes या value (secrets mask करके), browser और उसका version, और वह step लिखें जिसने उसे बदला: login, नया tab, restart या logout। Framework upgrades और stored formats बदलने वाली releases के बाद storage का व्यवहार अक्सर regress होता है, इसलिए ये checks regression suite में रखें और हर supported browser पर चलाएँ।

अभ्यास

Staff portal क्या रखता है: अनुमान लगाएँ और जाँचें

आपका काम

Login के बाद एक staff portal नीचे दी गई cookies और storage set करता है। हर item के लिए बताएँ कि वह कितने समय तक रहता है और tabs के बीच shared है या नहीं। फिर वे defects या risks लिखें जिन्हें आप report करेंगे, और तीन test cases जो पक्का करें कि logout काम करता है।

सामग्री
Response to POST /login
Set-Cookie: session=Qm91c2E1Vq; Path=/
Set-Cookie: theme=dark; Max-Age=86400; Path=/; SameSite=Lax

localStorage on https://portal.example
  user    {"name":"Sara Ali","email":"sara@example.com","token":"eyJhbGciOi..."}
  draft   "Notes for the Sunday meeting"

sessionStorage on https://portal.example
  wizard  {"step":3}
चरण
  1. हर item को classify करें: cookie, local storage या session storage; persistent या session।
  2. अनुमान लगाएँ कि नए tab, browser restart और logout के बाद क्या बचेगा।
  3. Security और privacy problems के लिए हर cookie के attributes और हर storage key का content जाँचें।
  4. Expected results के साथ logout के test cases लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

session में Expires या Max-Age नहीं, इसलिए यह हर tab में shared session cookie है जो browser session ख़त्म होने पर हटती है। theme persistent है: 86,400 seconds (एक दिन) रहती है, हर tab में shared है और उस दिन के भीतर restart के बाद भी बचती है। user और draft local storage में tabs और restarts के पार तब तक रहते हैं जब तक clear न हों। wizard सिर्फ़ उसी tab में है जिसने उसे बनाया: नया tab उसके बिना शुरू होता है, और tab बंद होने पर वह गायब हो जाता है।

Defects और risks: session में Secure और HttpOnly नहीं हैं, इसलिए यह plain HTTP पर जा सकती है और कोई भी script इसे पढ़ सकती है; इसमें explicit SameSite भी नहीं। user key ऐसा token रखती है जिसे कोई भी script पढ़ सकती है, और user का personal data browser बंद होने के बाद भी device पर रहता है। दोनों Set-Cookie lines कुकी एनालाइज़र (Cookie Analyzer) में paste करने पर missing attributes दिख जाते हैं।

Product owner से सवाल: क्या draft को logout के बाद बचना चाहिए? Shared computer पर अगला user सारा के notes देख लेगा।

Logout tests: (1) logout के बाद session delete होती है और user local storage से हटता है; (2) पुरानी session value या पुराने token के साथ दोबारा भेजी गई request login page या 401 Unauthorized लौटाती है, portal data नहीं; (3) एक tab में logout के बाद दूसरा tab अपने अगले action पर login page दिखाता है।

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

क्या session cookie और session storage एक ही हैं?

नहीं। Session cookie वह cookie है जिसमें Expires या Max-Age नहीं होता: browser उसे server को भेजता है, सभी tabs में share करता है और browser session ख़त्म होने पर हटा देता है। Session storage एक JavaScript store है जो एक tab का होता है, अपने आप server को नहीं जाता और उस tab के बंद होने पर clear हो जाता है।

Browser restart करने के बाद भी मेरी session cookie क्यों बची रही?

कई browsers start होने पर पिछला session restore कर सकते हैं, और तब session cookies भी restore हो जाती हैं, जैसे browser कभी बंद ही न हुआ हो। Browser की startup setting जाँचें, session restore बंद करके requirement test करें, और bug report में यह setting लिखें।

Application को login token कहाँ रखना चाहिए?

यह developers और security reviewers का design फ़ैसला है, लेकिन tester को trade-off पता होना चाहिए: HttpOnly, Secure cookie को scripts नहीं पढ़ सकतीं, जबकि web storage में रखी हर चीज़ कोई भी script पढ़ सकती है। दूसरी ओर cookie अपने आप भेजी जाती है, इसलिए उसे cross-site request forgery (CSRF) से सुरक्षा चाहिए: anti-CSRF tokens, और अतिरिक्त परत के रूप में SameSite। जो भी चुना जाए, test करें कि logout पर credential clear हो और उसके बाद server उसे reject करे।

संदर्भ

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

Mutqan tools से अभ्यास करें

कुकी एनालाइज़र

Set-Cookie हेडर पार्स करें और Secure, HttpOnly, SameSite, Domain, Path, एक्सपायरी तथा साइज़ की सर्वोत्तम प्रथाएँ जाँचें।

वैलिडेशन

HTTP हेडर पार्सर

कच्चे HTTP रिक्वेस्ट/रिस्पॉन्स हेडर को व्याख्या सहित एक संरचित तालिका में बदलें।

वेब

JWT डिकोडर

JWT का हेडर और पेलोड डिकोड करें, क्लेम जाँचें और एक्सपायरी देखें — पूरी तरह आपके ब्राउज़र में।

सुरक्षा

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा