कुकीज चोरी होने से रोकने के लिए एक तरीका मौजूद है? वेब 2.0 अनुप्रयोगों में

Question

कई उपयोगकर्ता आमतौर पर लॉग इन करना चाहते हैं ('मुझे याद रखें' ध्वज) और दूसरी ओर उनकी कुकी बहुत निजी डेटा तक पहुंच प्रदान कर सकती है। क्या कोई ऐसा व्यक्ति है जो कुकी को चुरा लेता है - सीधे कंप्यूटर से या स्नीफिंग के माध्यम से - उपयोगकर्ता के डेटा तक पहुंच प्राप्त करने के लिए कुकी का उपयोग कर सकता है? हमेशा HTTPS एक विकल्प नहीं है।

धन्यवाद, बर्न्ड

[संपादित करें] कनेक्ट कुकी के लिए आईपी पते एक विकल्प या तो नहीं है।

Answer 1

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

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

उपयोगकर्ता को यह विकल्प छोड़ दें कि वे लॉग इन रहते हैं या नहीं, और उन्हें अपनी जानकारी के बारे में चेतावनी दी जा रही है।

Answer 2

कुकी जार पर ढक्कन डालें।

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

Answer 3

बर्न्ड - मानक HTTP पर किए गए किसी भी चीज़ के साथ समस्या यह है कि यह सादा पाठ है; कोई भी नकली कुछ भी कर सकते हैं। आईपी ​​स्पूफिंग सिर्फ सादे कुकी चोरी से थोड़ा अधिक चुनौतीपूर्ण है, इसलिए आईपी को बांधना लोग क्या करते हैं। जैसा कि आपने कहा था, यह अत्यधिक गतिशील वातावरण के साथ बहुत अच्छी तरह से काम नहीं करता है।

एकमात्र अधिक सुरक्षित तरीका है जिसे मैं सोच सकता हूं कि "स्थायी" कुकी रखने और सत्यापित करने के लिए HTTPS का उपयोग करना है, और उसके बाद एक अल्पकालिक सत्र कुकी (उसी HTTPS सत्र में) रखें। प्रमाणीकरण के लिए सत्र कुकी का उपयोग करके शेष संचार नियमित HTTP पर किया जा सकता है।

इस तरह, कम संसाधनों का उपयोग एन्क्रिप्शन (केवल हैंडशेक) का समर्थन करने में किया जाता है, स्थायी कुकी का खुलासा नहीं किया जाता है - यह केवल एन्क्रिप्शन के तहत प्रेषित होता है - और सत्र कुकी को चोरी करना केवल सीमित जोखिम तक खुलता है, क्योंकि उस कुकी जल्दी समाप्त हो जाएगा।

यह सब कहा जा रहा है - उपयोगकर्ताओं को वास्तव में संवेदनशील डेटा वाले साइट पर "मुझे याद रखें" पर क्लिक न करें! यही कारण है कि बैंक इसे नहीं करते ..

उम्मीद है कि इससे मदद मिलती है।

Answer 4

डेटाबेस में जटिल कुकी आईडी और संबंधित आईपी संग्रहीत करने के बारे में - आपको वास्तव में ऐसा करने की ज़रूरत नहीं है। यदि आपके पास एक गुप्त कुंजी है, तो उपयोगकर्ता के आईपी को अपने के साथ एन्क्रिप्ट करने के लिए पर्याप्त है, और परिणाम {IP} K को कुकी के रूप में रखें। जब तक आपकी कुंजी सुरक्षित हो (और क्रिप्टो टूट नहीं गया है - लेकिन यदि ऐसा होता है, तो हमें बड़ी समस्याएं होती हैं), यह सुरक्षित है।

Answer 5

बेरेंड - आप कहते हैं कि कुकी में आईपी एड्रेस कनेक्ट करना एक विकल्प नहीं है, मुझे लगता है कि बी/सी उपयोगकर्ता को डीएचसीपी के माध्यम से जोड़ा जा सकता है, और इस प्रकार हर बार एक अलग आईपी के तहत आ सकता है। क्या आपने कुकी होस्ट को DNS होस्ट नाम पर बांधने पर विचार किया है? आप एक निजी कुंजी का उपयोग कर कुकी को एन्क्रिप्ट कर सकते हैं, और उसे उपयोगकर्ता के बॉक्स पर स्टोर कर सकते हैं। फिर जब भी वे अंदर आते हैं, कुकी को चेक करें, इसे एन्क्रिप्ट करें, और उसके बाद उपयोगकर्ता के वर्तमान DNS होस्ट नाम को कुकी में से एक के विरुद्ध जांचें। यदि यह मेल खाता है, तो आप उन्हें अनुमति देते हैं। यदि नहीं, तो आप ऑटो-लॉगिन की अनुमति नहीं देते हैं।

FYI करें - ASP.Net में, उपयोगकर्ता के बॉक्स के DNS होस्ट नाम पाने के लिए, बस पर

Page.Request.UserHostName 

Answer 6

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

इस परिदृश्य में, हमलावर निम्नलिखित तीन बातें करते हैं करने के लिए होगा:

पीड़ित के कुकीज़
1. चोरी
2. Spoof सही आईपी पते
3. Spoof सही उपयोगकर्ता एजेंट

यह यह सुनिश्चित करने में भी मदद करता है कि हमलावर पीड़ित के सत्र को सही तरीके से लेने के लिए सभी चीजों को पहले से ही नहीं जानता है। आईई: वे मान सकते हैं कि कुकी की आवश्यकता है और फिर असफल हो ... और एक बहुत लंबे परीक्षण और त्रुटि के माध्यम से सब कुछ पता लगाना होगा। इस तरह, आप हमलावर के कौशल और सिस्टम के अपने मौजूदा ज्ञान के आधार पर अस्पष्टता और कठिनाई के माध्यम से सुरक्षा प्राप्त करते हैं।

Answer 7

शायद सत्र आईडी और टोकन (आईपी, नमक, और सत्र आईडी पर आधारित हैश) का उपयोग करके, हर अनुरोध को पुन: उत्पन्न किया जाता है (एक तेज़ हैशिंग एल्गोरिदम का उपयोग) एक अच्छा दृष्टिकोण होगा? मैं डेटाबेस (वर्तमान में) में सत्र डेटा संग्रहीत करता हूं, और इसका मतलब है कि मेरे पास प्रत्येक अनुरोध के दो प्रश्न ओवरहेड हैं। यह इस तरह काम करता है:

1. एसआईडी और टीओके मैच का चयन करें।
2. डेटाबेस में मौजूदा क्लाइंट मैचों के आधार पर जेनरेट किए गए टोकन को सत्यापित करें।
3. किसी संपत्ति में डेटा को deserialise।
4. स्क्रिप्ट आदि हो रहा है।
5. अद्यतन डेटा को सीरियलाइज़ करें, एसआईडी/टीओके को पुन: उत्पन्न करें, और डीबी अपडेट करें जहां एसआईडी/टीओके = पुरानी सिड और टोक़, अद्यतन डेटा और नए सिड और टोक़। कुकी को नए एसआईडी और टोक़ पर सेट करें।

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

एकमात्र समझने योग्य कमजोरी मैं देख सकता हूं कि यदि हमलावर एक कुकी, स्पूफ और इसका उपयोग करने में कामयाब रहा, तो असली व्यक्ति एक और अनुरोध कर सकता था। इसे हल करने के कुछ तरीके हैं जिन्हें मुझे सोचने की ज़रूरत है।ओवरहेड दो प्रश्न हैं और एक टोकन हैश दो बार उत्पन्न करते हैं (एक बार सत्यापन के लिए, एक बार प्रतिस्थापन के लिए)।