2010-05-17 16 views
11

(मुझे लगता है) मैं समझता हूं कि जब उपयोगकर्ता लॉग इन करता है तो सत्र आईडी को घुमाया जाना चाहिए - session fixation को रोकने के लिए यह एक महत्वपूर्ण कदम है।क्या सत्र आईडी रोटेशन सुरक्षा को बढ़ाता है?

हालांकि, क्या यादृच्छिक रूप से/आवधिक रूप से घूर्णन सत्र आईडी के लिए कोई फायदा है?

ऐसा लगता है कि मेरी राय में केवल सुरक्षा की झूठी भावना प्रदान की जाती है। मान लीजिए सत्र आईडी ब्रूट-फोर्स अनुमान लगाने के लिए कमजोर नहीं हैं और आप केवल कुकी में सत्र आईडी (यूआरएल के हिस्से के रूप में नहीं) को प्रेषित करते हैं, फिर एक हमलावर को आपकी कुकी (संभवतः आपके यातायात पर स्नूपिंग करके) तक पहुंच प्राप्त करनी होगी सत्र आईडी। इस प्रकार यदि हमलावर को एक सत्र आईडी मिलती है, तो वे शायद घुमावदार सत्र आईडी को भी छीनने में सक्षम होंगे - और इस प्रकार यादृच्छिक रूप से घूर्णन में सुरक्षा में वृद्धि नहीं हुई है।

उत्तर

5

यदि आप कुकीज़ में संग्रहीत सत्र पहचानकर्ताओं का उपयोग कर रहे हैं, तो सत्र निर्धारण कोई समस्या नहीं है। मैंने आपके द्वारा पेस्ट किए गए पेपर के माध्यम से स्किम किया और मुझे उपयोगकर्ता के स्वामित्व के लिए DNS और XSS का उपयोग करने जैसी चीजें दिखाई देती हैं, जो स्पष्ट रूप से सत्र निर्धारण के मुकाबले बहुत अधिक (उल्लेख करने के लिए, अलग नहीं) मुद्दे हैं। यदि आपके पास कुकी में संग्रहीत सत्र पहचानकर्ता (एंट्रॉपी के स्वीकार्य स्तर के साथ) है, तो इसे घुमाने के लिए कोई सौहार्दपूर्ण कारण नहीं है। इसे घुमाए जाने का एकमात्र कारण यह होगा क्योंकि यह किसी अन्य तरीके से अनुमानित या कमजोर है, जिस स्थिति में उपयोगकर्ता को वैसे भी स्वामित्व मिल जाता है।

+5

मुझे लगता है कि लॉग इन करते समय सत्र आईडी (एसआईडी) घूर्णन करना आवश्यक है भले ही यह कुकी में संग्रहीत हो। इस पर विचार करें: हमलावर एक साझा कंप्यूटर पर वेबसाइट ब्राउज़ करता है और एक एसआईडी असाइन किया जाता है (लेकिन लॉगिन नहीं करता है)। फिर हमलावर दूर चला जाता है। यदि अगला उपयोगकर्ता लॉग इन करता है और एसआईडी घुमाया नहीं जाता है, तो हमलावर एसआईडी जानता है और इसे लॉग इन करने वाले उपयोगकर्ता के रूप में मास्कराइड करने के लिए इसका उपयोग कर सकता है। * यह परिदृश्य थोड़ा दूर है * (उम्मीद है कि साझा कंप्यूटर अभी भी अलग खाते हैं), * लेकिन संभव *। –

+2

आपने जो कहा वह एक गंभीर भेद्यता है (सोचो कियोस्क)। मुझे लगता है कि साइट लॉगिन पर एक नया सत्र आईडी असाइन कर रही है। बेशक, आपको लॉगिन पर एक नया सत्र आईडी असाइन करना चाहिए। और नहीं, यह हमला बिल्कुल दूर नहीं है। –

+0

सहमत हुए। (नोट: मेरी टिप्पणी मुख्य रूप से आपके उत्तर में पहली वाक्य के जवाब में थी) –

0

वेब विकास मेरी बात नहीं है, लेकिन संभवतः यह है क्योंकि उपयोगकर्ता लॉग इन करने वाला हमलावर हो सकता है? उदाहरण के लिए, यदि मैं लॉग इन करता हूं और सत्र आईडी 4 प्राप्त करता हूं, तो क्या मुझे लगता है कि सत्र आईडी 5 किसी अन्य उपयोगकर्ता से संबंधित होगा, मेरी स्थानीय कुकी संशोधित करेगा, और उसके बाद उस उपयोगकर्ता के रूप में कार्य करेगा?

+2

यह संभावना होगी कि यदि सत्र आईडी अनुक्रमिक रूप से उत्पन्न की गई हों। हालांकि, अच्छे सत्र आईडी जेनरेटर इस कारण से यादृच्छिक आईडी उत्पन्न करते हैं - इसलिए हमलावर उन्हें अनुमान नहीं लगा सकते हैं। –

0

कुल मिलाकर एक गूंगा विचार की तरह लगता है।

यह उपयोगकर्ताओं को पूरी तरह से खराब कर देगा यदि वे बैक बटन दबाते हैं क्योंकि पिछले पृष्ठ के लिंक में अब दिनांक सत्र आईडी शामिल है। आप किसी भी AJAX को भी फेंक सकते हैं क्योंकि प्रत्येक बार एक आरपीसी सर्वर पर बनाया जाता है, पृष्ठ पर सभी लिंक/रूपों को अद्यतन करने की आवश्यकता होती है क्योंकि उनके पास अब अमान्य मान हैं। यदि कुछ भी कम सुरक्षित है क्योंकि इसका मतलब है कि आपका आवेदन अधिक जटिल हो जाता है और इसमें कोई गलती होने का अधिक मौका होता है।

अगर तर्क आपको "घुमाने" की मांग करता है तो इसका मतलब है कि आपकी आईडी खराब रूप से उत्पन्न होती है, और यह वह चीज होनी चाहिए जो तय हो जाए। यदि स्नूपिंग एक समस्या है एसएसएल का उपयोग करें।

+2

मुझे नहीं लगता कि यह बैक बटन के साथ एक समस्या पैदा करता है। और मुझे लगता है कि आप एजेक्स/पास-एक साथ अनुरोधों को केवल हर आईडी अनुरोधों को सत्र आईडी घुमाकर, और छोटी अवधि के लिए पुराने लोगों को बनाए रख सकते हैं। बेशक, सिर्फ इसलिए कि यह उन चीजों को पेंच नहीं करता है इसका मतलब यह नहीं है कि यह एक अच्छा विचार है। मैं आपसे सहमत हूं कि मुझे नहीं लगता कि आवधिक सत्र आईडी रोटेशन या तो सार्थक है। मैं यह भी मानता हूं कि अगर स्नूपिंग समस्या है तो एसएसएल एक जरूरी है। –

+0

घुमाने/बदलने से आप प्रभावी रूप से घूर्णन बंद कर दिया है। तो क्या होगा यदि आपका ऐप एक पृष्ठ है और कभी भी नहीं बदलता है। उस पृष्ठ पर आपका AJAX अंततः सत्र आईडी TLD से पुराना हो जाएगा। –

+1

किसी भी तरह से URL में सत्र आईडी रखना एक बुरा विचार है। इसलिए, यदि सत्र आईडी को कुकी में व्यवस्थित रखा जाता है, तो एसपीए में बैक/फॉरवर्ड बटन असफल नहीं होंगे। – SteAp

0

इस SSL Labs ब्लॉग पोस्ट (2013 से) के अनुसार, आरसी 4 चिप्पर (अभी भी जंगली, 2017 में देखा गया) कमजोर है, जो ब्लैक टोपी को सत्र कुकी डेटा को अवरुद्ध एचटीटीपीएस यातायात (जैसे वाईफाई) से बेनकाब करने की अनुमति दे सकता है।

घूमने सत्र सत्र आईडी/डेटा प्रत्येक x समय इकाइयों (मिनट?), और प्रत्येक y अनुरोधों की संख्या के बाद, ब्लॉग पोस्ट में सुझाव दिया जाता है।

संबंधित मुद्दे