2009-07-25 14 views
48

मेरे पास एक लॉगिन स्क्रिप्ट है जो 'उपयोगकर्ता' तालिका में डेटा के विरुद्ध उपयोगकर्ता नाम/पासवर्ड सत्यापित करती है। इसके अलावा, मेरे पास एक 'भूमिका' तालिका है जो किसी दिए गए उपयोगकर्ता के पहुंच स्तर को निर्दिष्ट करती है। मान लीजिए कि मैं सुरक्षित लॉगिन स्क्रिप्ट का उपयोग कर रहा हूं, क्या उपयोगकर्ता के प्रमाणीकरण स्तर को खोजने और इसे सत्र चर में संग्रहीत करने के लिए 'भूमिका' तालिका के विरुद्ध सफल लॉगिन पर, अतिरिक्त क्वेरी करने में कोई सुरक्षा छेद है? विचार तब होगा कि मिश्रित प्राधिकारी वाले किसी भी पेज पर, मैं उपयोगकर्ता के प्रमाणीकरण स्तर में लॉग इन करने के लिए बस सत्र चर से पूछताछ कर सकता हूं।PHP सत्र चर कितने सुरक्षित हैं?

धन्यवाद।

उत्तर

69

सत्र, कुकीज़, कहानियों से काफी सुरक्षित हैं। लेकिन एक सत्र चोरी करना अभी भी संभव है और इस प्रकार हैकर के पास उस सत्र में जो कुछ भी है, उसकी कुल पहुंच होगी। इससे बचने के कुछ तरीके आईपी जांच (जो बहुत अच्छी तरह से काम करता है, लेकिन बहुत कम है और इस प्रकार अपने आप पर भरोसेमंद नहीं है), और एक nonce का उपयोग कर रहे हैं। आम तौर पर एक nonce के साथ, आपके पास एक प्रति पृष्ठ "टोकन" होता है ताकि प्रत्येक पृष्ठ जांचता है कि अंतिम पृष्ठ का नॉन जो संग्रहीत करता है उससे मेल खाता है।

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

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

+19

ध्यान दिया जाना चाहिए कि PHP सत्र आईडी को कुकी के रूप में संग्रहीत करता है। –

+0

+1 क्या आप एक गैरसे के बारे में अधिक समझा सकते हैं? संभव लिंक? – Petrogad

+5

nonce पर विकी आलेख बहुत हल्का है, लेकिन सभ्य लिंक हैं: http://en.wikipedia.org/wiki/Cryptographic_nonce मूल विचार, जैसा कि मैं इसे समझता हूं, एक टोकन की तरह है, लेकिन इसका उपयोग केवल एक बार किया जा सकता है (संख्या एक बार उपयोग की जाती है)। प्रत्येक पृष्ठ अनुरोध अंतिम nonce की जांच करता है और एक नया बनाता है। इसलिए यदि मैं आपके पासवर्ड पर एक बलपूर्वक बल हमला करने की कोशिश करता हूं, तो मुझे एक शॉट मिलता है, क्योंकि नॉन 2 राउंड पर मेल नहीं खाएगा। अगर मैं सत्र और उस पृष्ठ के नॉन को चुरा लेता हूं, तो मैं अनुरोध कर सकता हूं और गैर-नवीनीकरण कर सकता हूं आप एक अनुरोध करते हैं जो गैर-मैच से बाहर निकलता है। क्योंकि यह मेरा अनुरोध और मेरा नॉन देखेगा, अपडेट करें ... – Anthony

16

केवल आपके सर्वर पर निष्पादित स्क्रिप्ट को _SESSION सरणी तक पहुंच है। यदि आप सत्र कुकी के दायरे को परिभाषित करते हैं, तो आप इसे किसी विशिष्ट निर्देशिका तक भी सीमित कर सकते हैं। आपके अलावा कोई भी व्यक्ति एकमात्र तरीका प्राप्त कर सकता है कि सत्र डेटा कुछ PHP कोड को आपके पृष्ठों में से एक में इंजेक्ट करना है।

सिस्टम के लिए जो आप उपयोग कर रहे हैं, यह स्वीकार्य है और डेटाबेस कॉल को सहेजने का एक अच्छा तरीका है, लेकिन ध्यान रखें कि उपयोगकर्ता को लॉग इन करने और आवेदन करने के लिए किसी भी प्राधिकरण परिवर्तन के लिए फिर से लॉग इन करने की आवश्यकता होगी। इसलिए यदि आप एक खाता लॉक करना चाहते हैं और वह उपयोगकर्ता पहले ही लॉग इन है, तो आप नहीं कर सकते।

2

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

जहां तक ​​'सुरक्षा' जाती है - जब तक कि आप साझा मेजबान नहीं होते, तब तक चिंता करने की कोई बात नहीं है। एक उचित रूप से कॉन्फ़िगर किए गए साझा होस्ट पर, उन्हें अपेक्षाकृत सुरक्षित भी होना चाहिए।

13

यह ध्यान दिया जाना चाहिए कि अपाचे में PHP $ _SESSION superglobal वर्चुअलहोस्ट में पहुंच योग्य है।इस परिदृश्य पर विचार करें:

  • आपका सर्वर दो डोमेन, example.com और example.org होस्ट करता है। PHP सत्र कुकीज़ में संग्रहीत हैं जो डोमेन तक सीमित हैं।
  • कोई उपयोगकर्ता example.com में लॉग इन करता है और सत्र आईडी प्राप्त करता है। Example.com कुछ सत्र चर सेट करता है (जो सर्वर पर संग्रहीत हैं, कुकी में नहीं)।
  • एक तीसरी पार्टी ट्रांसमिशन के दौरान कुकी को रोकती है और इसे example.org पर भेजती है। Instance.org के पास अब example.com सत्र चर तक पहुंच है।

यह आपके द्वारा सर्वर पर सभी वर्चुअलहोस्ट को नियंत्रित करते समय इतना बड़ा सौदा नहीं है, लेकिन यदि आप साझा मशीन पर हैं, तो यह समस्याग्रस्त है।

+1

क्या आप जानते हैं कि यदि संभव हो तो एक sperglobal प्रति वर्चुअल होस्ट को प्रतिबंधित कैसे करें? – JRsz

+0

@JRsz आप उस निर्देशिका को बदल सकते हैं जहां session_save_path() फ़ंक्शन (http://php.net/manual/en/function.session-save-path.php) के माध्यम से सत्रों को आपके php.ini में संग्रहीत किया जाता है। – SandroMarques

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