2011-06-11 13 views
8

मैं कोडनिर्देशक का उपयोग कर एक वेब अनुप्रयोग विकसित कर रहा हूं। जब कोई उपयोगकर्ता मेरी साइट के साथ प्रमाणित करता है तो मैं वर्तमान में अपने सत्र कुकी में अपना 'उपयोगकर्ता-पहचानकर्ता' संग्रहीत कर रहा हूं (जिसे मैंने एन्क्रिप्शन सक्षम किया है)। मेरे कई मॉडल वर्ग उपयोगकर्ता खातों के गुणों में परिवर्तन करने के लिए सत्र/कुकी के 'उपयोगकर्ता-पहचानकर्ता' पैरामीटर में मान का उपयोग करते हैं।कोडनिर्देशक/PHP सत्र सुरक्षा प्रश्न

मेरी चिंता यह है कि मैं सोच रहा हूं कि किसी व्यक्ति के लिए वैध कोडिग्निटर-सत्र कुकी को मेरे द्वारा सेट किए गए उपयोगकर्ता-पहचानकर्ता के साथ संभव है, उपयोगकर्ता-पहचानकर्ता के मान को किसी भिन्न उपयोगकर्ता के मान में बदलें, और किसी अन्य उपयोगकर्ता के खाते में परिवर्तन करें। यदि कोई सत्र कुकी की संपत्ति बदलने का प्रयास करता है तो क्या कोडिनेटर/php सत्र एक त्रुटि उत्पन्न करेंगे?

उत्तर

19

अपना/appplication/config/config.php खोलें, "sess_use_database" का पता लगाएं और इसे "सत्य" में बदलें यदि आप पहले से नहीं हैं। इस प्रकार सभी सत्र चर डेटाबेस डेटाबेस में संग्रहीत किए जाएंगे और सत्र कुकी में केवल सत्र आईडी स्ट्रिंग होगी।

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

+3

नवीनतम कोडइग्निटर 3.0.1 के रूप में, 'sess_use_database' नाम' sess_driver' के साथ बदल दिया गया है जिसे 'डेटाबेस' पर सेट किया जा सकता है। नवीनतम दस्तावेज़ दावा करते हैं कि डिफ़ॉल्ट 'फ़ाइल' ड्राइवर सबसे सुरक्षित विकल्प है: http://www.codeigniter.com/user_guide/libraries/sessions.html –

+0

जानना बहुत बढ़िया है। – b3tac0d3

3

मुझे यकीन नहीं है कि आपका "उपयोगकर्ता पहचानकर्ता" वास्तव में क्या है। सामान्य नियम है, सत्र कुकी में कुछ भी स्टोर न करें लेकिन सत्र आईडी। सर्वर की तरफ आंतरिक रूप से अन्य सभी (जैसे उपयोगकर्ता आईडी) स्टोर करें, और सत्र आईडी का उपयोग करके इसे पुनर्प्राप्त करें।

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

+0

क्या आपको पता है कि कोडिनेटर के सत्र वर्ग में ऐसा करने की कार्यक्षमता है या नहीं? मैं मानता हूं कि यह एक अच्छा विचार है। उदाहरण के लिए, यदि मैं ऐसा करता हूं: $ this-> सत्र-> set_userdata ('id', 5); क्या यह मान उपयोगकर्ता को कुकी में आगे और आगे पास किया गया है या बस सर्वर पर संग्रहीत है और सत्र आईडी से जुड़ा हुआ है? –

+0

@ कैसी मैं सीआई से परिचित नहीं हूं, लेकिन [डॉक्स] के अनुसार (http: // codeigniter।कॉम/user_guide/पुस्तकालय/सत्र.html), डेटा वास्तव में कुकी में संग्रहीत किया जाता है। वे एक सुरक्षित डेटाबेस विकल्प दिखाते हैं हालांकि –

+0

मेरा 'उपयोगकर्ता पहचानकर्ता' मूल रूप से प्रत्येक उपयोगकर्ता के लिए मेरे उपयोगकर्ता की तालिका की प्राथमिक कुंजी है। मैं इसे प्रत्येक उपयोगकर्ता से जुड़े गुणों को संशोधित करने के लिए SQL क्वेरीज़ में उपयोग कर रहा हूं। मुझे पता है कि यह शायद भयानक है। –

4

"अगर यह एक वैध CodeIgniter-सत्र कुकी लेने के लिए किसी दूसरे उपयोगकर्ता के मूल्य को उपयोगकर्ता के पहचानकर्ता का मान बदल सकता है, और किसी अन्य उपयोगकर्ता के खाते में परिवर्तन करने।"

मेरा उत्तर वास्तव में सीआई से संबंधित नहीं है, इसलिए कृपया इसे ध्यान में रखें।

जब आप उपयोगकर्ता को "username1" लिखते हैं, तो क्लाइंट को वापस भेजा जाना चाहिए, लेखक उद्देश्यों के लिए, एक हैश होना चाहिए जो सर्वर उस उपयोगकर्ता से संबंधित है। ग्राहक और सर्वर के बीच सभी संचार उस हैश पर भरोसा करेंगे।

सर्वर प्रति उपयोगकर्ता एक अद्वितीय हैश उत्पन्न करेगा और हैश के पास रहने के लिए थोडा समय होना चाहिए। क्या कोई हैश कैप्चर कर सकता है और उस उपयोगकर्ता के रूप में पास कर सकता है? निश्चित रूप से। यही कारण है कि आपको सत्र के अपहरण को रोकने के लिए हैश से मेल खाने के लिए उपयोगकर्ता के एजेंट और आईपी की जांच करनी चाहिए।

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

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