एक सुरक्षित PHP लॉगिन और प्रमाणीकरण रणनीति विकसित करना

Question

मैं एक नई PHP साइट के लिए लॉगिन और प्रमाणीकरण प्रणाली विकसित कर रहा हूं और विभिन्न हमलों और भेद्यताओं पर पढ़ रहा हूं। हालांकि, यह थोड़ा उलझन में है, इसलिए मैं यह देखना चाहता हूं कि मेरा दृष्टिकोण समझ में आता है।

• सत्र में:

  मैं निम्नलिखित डेटा भंडारण पर योजना उपयोगकर्ता के आईडी, टुकड़ों में बांटा + नमकीन HTTP_USER_AGENT

• कुकी में और डेटाबेस में: यादृच्छिक टोकन , धोया + नमकीन पहचानकर्ता

प्रत्येक पृष्ठ पर, मैं निम्न कार्य पर योजना: एक सत्र मौजूद है

1. , तो उस का उपयोग करके प्रमाणित। जांचें कि HTTP_USER_AGENT संग्रहित सत्र में से किसी एक से मेल खाता है।

2. यदि कोई सत्र मौजूद नहीं है, तो कुकी को प्रमाणित करने के लिए उपयोग करें। जांचें कि कुकी में टोकन और पहचानकर्ता डेटाबेस में उनसे मेल खाता है।

3. यदि कुकी अमान्य है या मौजूद नहीं है, तो उपयोगकर्ता से लॉगिन करने के लिए कहें।

क्या इसमें कोई स्पष्ट त्रुटियां हैं? जब तक मैं कुकी में टाइमआउट सेट करता हूं, मुझे काफी सुरक्षित होना चाहिए, है ना? क्या मुझे कुछ याद आ रही है?

अग्रिम में बहुत धन्यवाद।

Answer 1

कुछ यादृच्छिक विचार:

1. क्या होगा यदि मैं अपने उपयोगकर्ताओं में से एक (अपनी वेबसाइट में कुछ जे एस कोड इंजेक्शन लगाने के द्वारा एक XSS हमले का प्रयोग करके) की कुकी चोरी? मैं फिर 2 मामले में गिर जाऊंगा। और इस प्रकार लॉग इन करने में सक्षम हो। IMHO, यदि आप वास्तव में सुरक्षित प्रमाणीकरण चाहते हैं, तो "मुझे याद रखें" का उपयोग न करें- उपयोगकर्ता प्रमाण-पत्रों को संग्रहीत करने के लिए कुकीज़ टाइप करें।
2. यदि आप कुकी में क्रेडेंशियल स्टोर करते हैं, तो कृपया पासवर्ड को स्पष्ट रूप से स्टोर न करें।
3. HTTP_USER_AGENT के लिए जांच सत्र अपहरण को रोकने के लिए एक अच्छा पहला कदम है, लेकिन हो सकता है कि आप इसे आईपी पते से जोड़ सकें? उसी ब्राउज़र का उपयोग करने के बजाय अपने लक्ष्य की तुलना में एक ही मेजबान पर होना कहीं अधिक कठिन है।

लेकिन किसी भी मामले में, एक अच्छी प्रमाणीकरण योजना के बारे में सोचने का समय लेने के लिए धन्यवाद। बहुत से PHP डेवलपर्स नहीं करते हैं।

संपादित करें: रिकॉर्ड के लिए, मुझे यहां एक बिंदु स्पष्ट करने दें: इस भ्रम में दो कुकीज़ हैं। सत्र आईडी को प्रचारित करने के लिए PHP द्वारा स्वचालित रूप से सेट किया जा रहा है (कभी-कभी, हम इसे URL में डालकर वेबसाइट देखते हैं, उदाहरण के लिए www.example.com/page.php?sessionId = [...]), और दूसरा आपके द्वारा बनाया गया उपयोगकर्ता प्रमाण-पत्रों को संग्रहीत करने के लिए और सत्र खो जाने पर उसे प्रमाणित करें। एक्सएसएस हमला दोनों पर लागू होता है, यानी एक हमलावर या तो सत्र कुकी चुरा सकता है और सत्र को हाइजैक कर सकता है (जिसमें सीमित जीवनकाल है), या क्रेडेंशियल कुकी चुराएं और बाद में प्रमाणीकृत करें।

Answer 2

नहीं होना चाहिए। PHP सर्वर आपके सर्वर पर उपयोगकर्ता को संग्रहीत नहीं किया जाता है। php सिपाही एक सत्र कुकी इसे इंगित करता है। यदि आप साझा होस्टिंग सत्र पर नहीं हैं, तो उसे भी धोना नहीं पड़ता है।

जो

Answer 3

कैसे सुरक्षित आप होना चाहते हैं पर निर्भर करता है ..

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

दूसरा: यदि आपके पास उच्च से अधिक ट्रैफ़िक है, तो सत्र आईडी को दोहराया जा सकता है या अनुमान लगाया जा सकता है, मैं उपयोगकर्ताओं की कुकीज़ में संग्रहीत दूसरी हाथ से उत्पन्न आईडी के खिलाफ जांच करता हूं।

Answer 4

यह योजना कुछ तरीकों से अनिवार्य रूप से जटिल लगती है, जिसमें अतिरिक्त जटिलता आपको कार्यक्षमता या सुरक्षा में कुछ भी नहीं प्राप्त करती है।

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

उपयोगकर्ता-एजेंट गुप्त डेटा नहीं है, इसलिए यह अनावश्यक है।

हमलों कि सत्र कुकी + रिमोट आईपी जाँच पकड़ नहीं होगा:

1. हमलावर
2. ब्लाइंड इंजेक्शन हमलों, जहां हमलावर पैरोडी उपयोगकर्ता के आईपी उपयोगकर्ता के रूप में ही नेट के पीछे है। केवल लिखने के बावजूद, ये अभी भी कुछ नुकसान कर सकते हैं।
3. हमले जो उपयोगकर्ता के अपने ब्राउज़र का उपयोग करते हैं, जैसे cross-site request forgery (CSRF)।

2) यदि आप उपयोगकर्ता के ब्राउज़र को चुनौती देने का एक तरीका काम कर सकते हैं, तो इसे रोका जा सकता है, जिसे अनुरोध पूरा करने से पहले जवाब दिया जाना चाहिए, लेकिन जब आप क्लाइंट नहीं लिखते तो यह मुश्किल है। AJAX के साथ यह किया जा सकता है। 3) (जैसा कि माइंडस्टॉकर द्वारा नोट किया गया है) रेफरर हेडर की जांच करके रोका जा सकता है, जो काम करता है क्योंकि सीएसआरएफ हमलों में मनमानी शीर्षकों को प्रभावित करने की क्षमता नहीं है, और XMLHttpRequest को रेफरर हेडर सेट करने की अनुमति नहीं देनी चाहिए (W3C standard के अनुसार हालांकि कार्यान्वयन अनुपालन नहीं हो सकता है)। Iframes के साथ, रेफरर चेक के आसपास जाना संभव हो सकता है। साथ ही, रेफरर हेडर क्लाइंट-साइड अवरुद्ध हो सकता है।

Answer 5

डेटाबेस में कुकी संग्रहीत करना एक हॉरिलब विचार है। इसका मतलब है कि अगर किसी हमलावर के पास एसक्यूएल इंजेक्शन भेद्यता होती है तो वह तुरंत धोए गए पासवर्ड को तोड़ने के बिना पहुंच प्राप्त कर सकता है।

बोलने के लिए आपको पासवर्ड के लिए sha256 का उपयोग करने की आवश्यकता है, यदि आप md5() का उपयोग करते हैं तो आप तकनीकी रूप से हमले के लिए कमजोर हैं और आपको सीवी संख्या जारी की जा सकती है।

कभी भी अपना स्वयं का सत्र आईडी उत्पन्न नहीं करें, session_start() और $ _SESSION सुपर ग्लोबल का उपयोग करें।

यह लोगों को पुनर्निर्देशित करने का एक सुरक्षित तरीका है। आप() हेडर के बाद मर जाते हैं नहीं है, तो php कोड के बाकी अभी भी निष्पादित किया जाता है, भले ही सामान्य ब्राउज़र द्वारा अपनी प्रदर्शित नहीं (हैकर्स अभी भी इसे देख :) अगर सुरक्षा आप confuses

header("location: index.php"); 
die(); 

ईमानदारी से कहूं तो डॉन सुरक्षा प्रणाली नहीं लिखो। लोगों ने अकेले PHP के लिए 1,000 से अधिक लॉगिन सिस्टम लिखे हैं और बहुमत कमजोर हैं। इस प्रोजेक्ट में एक सुरक्षित प्रमाणीकरण प्रणाली है: http://code.google.com/p/michael-the-messenger/downloads/list

Answer 6

अधिकांश साइटें केवल PHP सत्र का उपयोग करती हैं; सत्र डेटा ($ _SESSION) पर सर्वर पर है। ब्राउजर को जो कुछ भेजा गया है वह एक सत्र आईडी है। प्रत्येक अनुरोध (session_regenerate_id) सत्र को पुन: उत्पन्न करना सुनिश्चित करें। आपको दो कुकीज़ या कुछ भी भेजने की आवश्यकता नहीं है।

यह सत्र अपहरण के लिए कम असुरक्षित है क्योंकि प्रत्येक अनुरोध एक नई आईडी है, इसलिए हमलावर द्वारा अवरुद्ध एक पुराना व्यक्ति बेकार है।

सबसे अच्छा समाधान, जाहिर है, पूरे सत्र में एसएसएल का उपयोग करना होगा।

Answer 7

आईएमएचओ यह भी महत्वपूर्ण है कि सफल लॉगिन के बाद सत्र सूचनाएं बदल दी जाएंगी। किसी डेटाबेस में सत्र जानकारी को सहेजने के लिए इंजेक्शन के कारण सहेजा नहीं जाता है।

Answer 8

- नमक के साथ sha1 का उपयोग करें - निश्चित रूप से आपको यह परिभाषित करना होगा कि प्रत्येक रूप सुरक्षित नहीं है इसलिए हर रूप के लिए टोकन का उपयोग किया जाता है। कि आप प्रत्येक फॉर्म एंट्री बनाते हैं और preg_match का उपयोग करके इसे sanitize करते हैं। स्वच्छता नामक एक प्रक्रिया।