मॉड्यूल 17 · सिक्योरिटी टेस्टिंग

सेशन मैनेजमेंट टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 20 मिनट · मध्यम

Session management testing जाँचती है कि application उन sessions को कैसे बनाता, सुरक्षित रखता, renew करता और ख़त्म करता है जो users को logged in रखते हैं। यह पाँच सवाल पूछती है: क्या identifiers का अनुमान लगाया जा सकता है? क्या login से पहले plant किया गया identifier login के बाद इस्तेमाल हो सकता है (session fixation)? क्या idle timeout और absolute timeout लागू होते हैं? क्या logout server पर session ख़त्म करता है? और क्या हर session cookie पर सही flags हैं?

उदाहरण: एक HR portal login page से dashboard तक वही identifier रखता है। Login काम करता है, इसलिए हर functional test pass होता है, फिर भी जिसने login से पहले वह value employee के browser में डाल दी थी, वह अब employee का session share करता है। इसे सिर्फ़ वह test पकड़ता है जो पुराना identifier replay करता है।

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

Server के लिए, जो भी valid session identifier भेजता है वही logged-in user है, बिना password और बिना second factor के। इसलिए अनुमान लगाने लायक, plant किया गया, leak हुआ या कभी ख़त्म न होने वाला identifier मज़बूत login को कमज़ोर बना देता है।

ये defects functional testing में कभी नहीं दिखते, क्योंकि user की अपनी journey काम करती है। इन्हें सिर्फ़ इन्हीं के लिए design किए गए tests पकड़ते हैं, और ज़्यादातर सस्ते हैं: दो browser profiles, developer tools और एक test account। OWASP Web Security Testing Guide (WSTG) में session management tests की पूरी category है; यह lesson उसके मुख्य tests को ऐसी test conditions में बदलता है जिन्हें आप हर release पर चला सकते हैं।

Session lifecycle एक state model के रूप में

Cookies and sessions over HTTP वाले lesson में आपने एक session को हाथ से trace किया था। Security test plan को हर उस तरीके को cover करना चाहिए जिससे session शुरू होता है, बदलता है और ख़त्म होता है, और state model, जैसा state transition testing में, इसे साफ़ दिखाता है: कोई session नहीं, anonymous session (कई applications इसे login से पहले बनाते हैं), signed in, idle, और ended। हर transition एक test condition है।

पूरे model पर एक नियम लागू होता है: login पर, हर privilege change पर और session ख़त्म होने के हर तरीके पर पुराना identifier server पर काम करना बंद कर दे; सिर्फ़ signed in और idle के बीच आने-जाने में वही identifier रहता है। Check हमेशा एक ही है: पुराने identifier की copy रखें, transition के बाद उसे replay करें, और login page या 401 की उम्मीद करें, user का data कभी नहीं। Expected values, जैसे दोनों timeouts और दूसरे sessions ख़त्म करने वाले events, team की session policy से आती हैं।

Login session एक state machine के रूप में: login, हर privilege change और session का हर अंत server पर पुराना identifier ख़त्म करे, इसलिए ऐसा हर numbered transition एक test है जिसे पुराने identifier के replay से जाँचा जाता है। वैचारिक मॉडल
ट्रांज़िशन
#सेतकEvent / server को क्या करना चाहिए
1कोई session नहींशुरुआतAnonymous session Aपहली visit / server login से पहले का id A देता है (अगर application बनाता है)
2Anonymous session ASigned in Bमौजूदा स्टेटLogin सफल / नया id B; अब A का replay login page पाता है
3Signed in Bमौजूदा स्टेटSigned in Bमौजूदा स्टेटPrivilege change (re-authentication, role switch) / नया id; पिछला id काम करना बंद करता है
4Signed in Bमौजूदा स्टेटSigned in, idleUser की कोई request नहीं
5Signed in, idleSigned in Bमौजूदा स्टेटIdle limit से पहले user की request / idle timer फिर से शुरू
6Signed in, idleServer पर ख़त्मअंतServer की घड़ी पर idle limit पूरीवैकल्पिक पथ
7Signed in Bमौजूदा स्टेटServer पर ख़त्मअंतLogout / server session record delete करता है
8Signed in Bमौजूदा स्टेटServer पर ख़त्मअंतAbsolute limit पूरी, password change या administrator का revoke करनावैकल्पिक पथ

Simplified model: असली applications remembered device या locked account जैसी states जोड़ सकते हैं।

आज़माएँ: स्टेट ट्रांज़िशन जनरेटर

Identifier randomness: structure ढूँढें

OWASP Session Management Cheat Sheet ऐसे identifiers माँगती है जो cryptographically secure random generator से बने हों और जिनमें कम से कम 64 bits entropy हो; OWASP Application Security Verification Standard (ASVS) का version 5.0 कम से कम 128 bits माँगता है, इसलिए वही minimum लें जो आपकी team की policy अपनाती है। देखकर randomness साबित नहीं की जा सकती, लेकिन वह structure ढूँढा जा सकता है जो उसे ग़लत साबित करे। एक test account से लगभग 20 बार और दूसरे से कुछ बार login करें, हर identifier उसके समय के साथ लिखें, और उन्हें एक के नीचे एक रखें।

  • Length सिर्फ़ ऊपरी सीमा देती है: 32 hexadecimal characters में ज़्यादा से ज़्यादा 128 bits होते हैं। अगर उनमें से 24 कभी नहीं बदलते, तो बाक़ी 8 में ज़्यादा से ज़्यादा 32 bits हैं, यानी minimum से कम।
  • ऐसा prefix जो हर value में हो, या ऐसा हिस्सा जो हर login पर एक बढ़ता है, counter है, randomness नहीं।
  • Value को Base64 के रूप में decode करें और लंबे numbers को Unix timestamps (1 January 1970 UTC से गिने गए seconds या milliseconds) के रूप में convert करें: अंदर user id, email या login का समय मिले तो identifier बनाया गया है, random नहीं।
  • उसी user का दूसरा login पूरी तरह अलग value दे, और identifier कभी URLs, page source या error messages में न दिखे।
  • ये checks structure पकड़ते हैं पर उसकी ग़ैरमौजूदगी साबित नहीं करते। बड़े sample का statistical analysis, जैसे Burp Suite के Sequencer से, specialists का काम है; सबसे मज़बूत सबूत यह है कि identifier framework का built-in session manager बनाता है, जिसकी सलाह OWASP homemade solution की जगह देता है।

आज़माएँ: Base64 डिकोडर आज़माएँ: टाइमस्टैम्प कन्वर्टर

Worked example: session fixation टेस्ट करना

Session fixation में attacker identifier चुराता नहीं, plant करता है: वह login से पहले का एक valid identifier लेता है, उसे victim के browser तक पहुँचाता है, जैसे URL में उसे ले जाने वाले link से या sibling subdomain से set की गई cookie से, और login का इंतज़ार करता है। अगर application वही identifier रखता है, तो attacker की copy अब signed in है।

Set-up: test environment में staff portal https://hr.example, एक test account और दो browser profiles: A attacker के लिए, B employee के लिए। सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की आपके पास लिखित अनुमति है। Trace में A की visit, cookie हाथ से set करने के बाद B का login, और A का replay दिखता है।

  • A में login page खोलें और login से पहले का sid copy करें। B में developer tools के storage panel से sid को वही value दें, फिर login करें।
  • Expected: login response नया sid set करता है, और A में /dashboard reload करने पर login page आता है। अगर A को employee का dashboard दिखे, तो session fixed है: severity Critical प्रस्तावित करें।
  • ऐसी value के साथ दोहराएँ जो server ने कभी issue नहीं की, जैसे sid=tester-made-0001। Strict session manager उसे ignore करके अपनी value देता है; जो उसे स्वीकार कर ले, उसे OWASP permissive कहता है। Renewal login को बचा भी ले, तब भी इसे report करें।
  • हर privilege change पर दोहराएँ: sensitive action से पहले re-authentication, role या organisation बदलना, और उसी browser पर दूसरे user का login। जब session cookie में चलता है, तो URL में identifier, जैसे ?sid= या ;jsessionid=, ignore होना चाहिए।
GET /login HTTP/1.1
Host: hr.example

HTTP/1.1 200 OK
Set-Cookie: sid=Pq7Lm2Vx9Rt4Kw8N; Path=/; Secure; HttpOnly; SameSite=Lax

POST /login HTTP/1.1
Host: hr.example
Cookie: sid=Pq7Lm2Vx9Rt4Kw8N

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

GET /dashboard HTTP/1.1
Host: hr.example
Cookie: sid=Pq7Lm2Vx9Rt4Kw8N

HTTP/1.1 302 Found
Location: /login

आज़माएँ: cURL जनरेटर

Timeouts और logout: session ख़त्म होने का हर तरीका

आप पहले से जानते हैं कि दोनों timeouts को boundary values से कैसे टेस्ट करें और logout के बाद identifier कैसे replay करें। Security level पर यह भी टेस्ट करें कि session ग़लती से ज़िंदा कैसे रहता है, और हर वह event जिसे उसे ख़त्म करना चाहिए। हर request का समय लिखें: फ़ैसला server की घड़ी करती है, page नहीं।

  • Background traffic: server को poll करने वाला page, जैसे notification counter, limit से ज़्यादा देर idle छोड़ें। अगर polling को activity माना जाता है, तो session idle होकर कभी ख़त्म नहीं होगा; पूछें कि क्या यह intended है।
  • Warning dialogs: "Stay signed in" को server पर session बढ़ाना चाहिए, और warning को ignore करने पर session वहीं ख़त्म होना चाहिए, सिर्फ़ page छिपना काफ़ी नहीं। कोई भी activity absolute timeout नहीं बढ़ाती।
  • Tabs और devices: एक tab में logout हर tab का session ख़त्म करे, और "Log out of all devices" दूसरे browser profile का session भी ख़त्म करे।
  • Password change: ASVS किसी भी authentication factor के बदलने के बाद बाक़ी सभी sessions ख़त्म करने का option चाहता है, जैसे password change, password reset से हुए change समेत, या MFA settings का update। वह यह भी चाहता है कि disabled या deleted account के सभी sessions ख़त्म हों; हटाए गए roles के बारे में policy क्या कहती है, यह पूछें।
  • हर credential: remember-me cookie (persistent cookie जो password के बिना user को फिर से sign in कर देती है), refresh token (लंबे समय तक चलने वाला token जिससे नए access tokens मिलते हैं) या single-page app का access token भी logout पर काम करना बंद करे। हर एक को replay करें।
  • Logout के बाद Back button browser history से page दोबारा दिखा सकता है। यह caching का सवाल है; reload करें या कुछ भी click करें, server को login page से जवाब देना चाहिए।

आम गलतियाँ

  • दो-तीन identifiers के सिर्फ़ अलग दिखने से randomness का फ़ैसला करना।
  • Renewal को सिर्फ़ server के issue किए identifier से टेस्ट करना, दूसरे profile से plant किए या tester के बनाए identifier से नहीं।
  • Page पर warning या login form दिखते ही timeout test ख़त्म कर देना, बिना यह जाँचे कि अगली request पर server क्या जवाब देता है।
  • Logout के बाद सिर्फ़ main session cookie replay करना और remember-me cookies, refresh tokens और API tokens भूल जाना।
  • Cookie flags सिर्फ़ login response पर जाँचना, renewals, refreshes और "remember me" logins पर नहीं।
  • लिखित अनुमति के बिना system टेस्ट करना, या live identifiers को mask किए बिना reports और chats में paste करना।

QA का नज़रिया

Login के पीछे की पहली feature से ही session tests plan करें, session policy को test basis बनाकर। Product owner और security lead से values और rules माँगें, और state model के हर transition को ऐसे test case में बदलें जिसके expected result में पुराने identifier का replay शामिल हो।

यह व्यवहार ज़्यादातर framework या gateway configuration है, इसलिए upgrades और infrastructure changes के बाद tests दोबारा चलाएँ। Bug report में transition, पहले और बाद के masked identifiers, timestamps और server का जवाब दें। Exploitation और statistical analysis security specialists पर छोड़ें, और test environment के बाहर कुछ भी टेस्ट करने से पहले उनसे scope तय करें।

अभ्यास

Pharmacy portal के पहले session tests परखें

आपका काम

आपके test environment में एक pharmacy portal है जिसे टेस्ट करने की आपके पास लिखित अनुमति है। उसकी session policy: 15 मिनट का idle timeout और 8 घंटे का absolute timeout, दोनों server पर; login पर और हर privilege change पर नया identifier; logout session ख़त्म करता है; password change बाक़ी सभी sessions ख़त्म करता है।

आपके पहले tests से नीचे का material और तीन observations मिले: login से पहले का sid login के बाद replay करने पर dashboard खोलता है; हर 60 seconds पर /api/notifications poll करने वाला tab 40 मिनट idle रहने के बाद भी signed in है; profile 1 में password change के बाद profile 2 अब भी order history load करता है। हर finding के लिए area, टूटा हुआ rule, प्रस्तावित severity और fix का confirmation test लिखें।

सामग्री
Test user 2041 के पाँच logins के बाद identifiers
sid=s-2041-8f3a01
sid=s-2041-8f3a02
sid=s-2041-8f3a03
sid=s-2041-8f3a04
sid=s-2041-8f3a05

"remember me" के बिना login response
Set-Cookie: sid=s-2041-8f3a05; Path=/; Secure; HttpOnly; SameSite=Lax

"remember me" के साथ login response
Set-Cookie: sid=s-2041-8f3a06; Path=/; Max-Age=2592000
चरण
  1. Identifiers को एक के नीचे एक रखें और कभी न बदलने वाले और गिनती करने वाले हिस्से चिह्नित करें।
  2. दोनों Set-Cookie lines को attribute by attribute मिलाएँ।
  3. हर observation को session state model के किसी transition पर रखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Randomness: 2041 user id है, 8f3a0 कभी नहीं बदलता, और आख़िरी digit गिनती करता है, जो अगले login पर 06 तक जाता है। एक identifier देखने वाला बाक़ी का अनुमान लगा सकता है। Rule: OWASP का कम से कम 64 bits entropy वाला, बिना अर्थ का random identifier; यहाँ सिर्फ़ एक hexadecimal character, यानी ज़्यादा से ज़्यादा 4 bits, बदलता है। Severity: Critical। Confirmation test: नए sample में कोई shared, बढ़ता या पढ़ने लायक हिस्सा न हो, और team पुष्टि करे कि identifier framework का secure generator बनाता है।

Fixation: login के बाद के identifiers में user id है, इसलिए login पर identifier सच में बदलता है, लेकिन login से पहले वाला अब भी dashboard खोलता है; invalidation के बिना renewal plant की गई value को काम का छोड़ देता है। Rule: login पर नया identifier, और पुराना server पर ख़त्म। Severity: Critical। Confirmation test: इस lesson का दो profiles वाला test; B के login के बाद A का replay login page पर पहुँचे।

Timeout: polling idle timer reset करता है, इसलिए tab खुला रहने तक 15 मिनट का rule लागू ही नहीं होता। Severity: Major, जब तक policy polling को activity न माने। Confirmation test: polling tab खुला हो और user की कोई action न हो; 16 मिनट बाद पहली action login page पर पहुँचे, और 14 मिनट बाद वाली action अब भी काम करे।

Revocation: password change ने दूसरा session ख़त्म नहीं किया, इसलिए session चुराने वाला user के password बदलने के बाद भी उसे रखता है। Severity: Critical। Confirmation test: profile 1 में change के बाद profile 2 की अगली request login page पर पहुँचे; password reset से हुए change के साथ दोहराएँ।

Cookie flags: "remember me" वाला response Secure, HttpOnly और SameSite छोड़ देता है और session cookie को 30 दिन रखता है। Rule: cookie set करने वाले हर response पर session cookie का baseline। Severity: Major; यह भी पूछें कि क्या "remember me" के लिए अलग, revoke की जा सकने वाली cookie होनी चाहिए। Confirmation test: Cookie Analyzer दोनों responses पर वही flags दिखाए।

अभी टेस्ट करना बाक़ी: लगातार activity के बावजूद 8 घंटे का absolute timeout, logout के बाद sid और remember-me cookie का replay, और privilege changes पर renewal।

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

क्या security tools के बिना session management टेस्ट कर सकते हैं?

ज़्यादातर, हाँ। दो browser profiles, developer tools, एक test account और curl जैसा command-line client renewal, fixation, timeouts, logout और cookie flags के लिए काफ़ी हैं। Randomness का statistical analysis और automated scanners specialists का काम है; जब risk माँगे तो security team को शामिल करें।

Application session identifier की जगह JWT इस्तेमाल करे तो क्या बदलता है?

सवाल वही रहते हैं, checks बदलते हैं। Signed JWT का payload सिर्फ़ encoded होता है, encrypted नहीं, इसलिए उसे decode करें और देखें कि उसमें sensitive data न हो और exp छोटा हो। Server आम तौर पर JWT का record नहीं रखता, इसलिए logout और password change के लिए अतिरिक्त design चाहिए, जैसे short-lived access tokens के साथ revoke किए जा सकने वाले refresh tokens: logout के बाद दोनों replay करके देखें कि application असल में क्या करता है।

Randomness परखने के लिए कितने identifiers चाहिए?

इस lesson के visual checks के लिए कुछ दर्जन identifiers counters, timestamps और fixed हिस्से दिखाने को काफ़ी हैं। आँख से पढ़ा कोई sample यह साबित नहीं करता कि values काफ़ी random हैं; उसके लिए statistical analysis या proven generator का सबूत चाहिए। जो देखा वह report करें, यह नहीं कि identifier secure है।

अगर कोई identifier plant नहीं कर सकता, तो क्या missing renewal फिर भी defect है?

हाँ। Missing renewal वही कमज़ोरी है जिसका fixation फ़ायदा उठाता है, और planting के रास्ते, जैसे sibling subdomain से set की गई cookie या injected script, बाद में सामने आ सकते हैं। OWASP Session Management Cheat Sheet login पर नया identifier हर हाल में ज़रूरी मानती है।

संदर्भ

  • OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
  • OWASP Cheat Sheet Series: Session ManagementOWASP Foundationसेशन आइडेंटिफ़ायर की एंट्रॉपी, कुकी एट्रिब्यूट, एक्सपायरी, लॉगिन के बाद नवीनीकरण और लॉगआउट हैंडलिंग।
  • OWASP Application Security Verification Standard (ASVS)OWASP Foundationवेब एप्लिकेशन के लिए सत्यापन-योग्य सुरक्षा आवश्यकताओं की चेकलिस्ट, तीन एश्योरेंस स्तरों में।
  • Using HTTP cookies — MDNMDN Web Docs (Mozilla)कुकी की अवधि, स्कोप, Secure/HttpOnly/SameSite एट्रिब्यूट और उनके सुरक्षा निहितार्थ।
टूल्स

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

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

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

वैलिडेशन

स्टेट ट्रांज़िशन जनरेटर

states और events परिभाषित करें, फिर transition तालिका, वैध/अमान्य transition टेस्ट और 0-switch/1-switch coverage जनरेट करें।

टेस्ट डिज़ाइन

Base64 डिकोडर

Base64 या Base64url स्ट्रिंग को टेक्स्ट में डिकोड करें, पैडिंग अपने आप ठीक होने के साथ।

एन्कोडिंग

टाइमस्टैम्प कन्वर्टर

टाइमस्टैम्प (सेकंड, मिलीसेकंड, माइक्रोसेकंड) को पढ़ने योग्य तारीख़ में और वापस बदलें, किसी भी timezone में।

यूटिलिटीज़

cURL जनरेटर

मेथड, URL, हेडर, बॉडी और auth विकल्पों से cURL कमांड बनाएँ।

वेब

JWT डिकोडर

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

सुरक्षा

और गहराई से

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

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