2011-04-20 12 views
15

मुझे आश्चर्य है कि सत्र में उपयोगकर्ता आईडी को संग्रहीत करने के जोखिम क्या हैं?php उपयोगकर्ता आईडी संग्रहित?

तो बस एक

if(isset($_SESSION['user_id'])){ 
    login_user($_SESSION['user_id]); 
} 

सत्र एन्क्रिप्टेड रहे हैं पर्याप्त है कि हम उन्हें hashing के बारे में चिंता करने की ज़रूरत नहीं होते कर? कोई व्यक्ति अपनी आईडी बदलने में सक्षम होने की संभावना क्या है?

+0

यह ध्यान देने योग्य है कि यदि कोई उपयुक्त प्लगइन है (मैं फ़ायरफ़ॉक्स के लिए वेब डेवलपर का उपयोग करता हूं) तो उपयोगकर्ता अपनी सत्र जानकारी देख सकता है।इसके अलावा आप 'login_user कॉल – DaOgre

+5

@DaOgre * सत्र * जानकारी में दूसरा' खो रहे हैं! == * कुकी * जानकारी – deceze

+0

बहुत अच्छी बात @deceze। मैंने जल्दी से जांच की और सत्र आईडी को संग्रहीत किया, और कुछ त्वरित (और गलत) मानसिक छलांग लगाई। पकड़ – DaOgre

उत्तर

10

सत्र डिफ़ॉल्ट रूप से फ़ाइल के रूप में /tmp में संग्रहीत किया जाता है। यह अंतिम उपयोगकर्ता द्वारा तब तक देखने योग्य नहीं है जब तक आपके पास directory traversal भेद्यता जैसी सुरक्षा समस्याएं न हों।

क्लाइंट को देखने वाला एकमात्र हिस्सा एक कुकी में संग्रहीत अद्वितीय हैश सर्वर पर प्रासंगिक सत्र में मानचित्र करता है।

0

यदि कोई आपके सत्र तक पहुंच सकता है, तो शायद वह बहुत अधिक पहुंच सकता है। मैं इसे हश नहीं करता और यह भी सुनिश्चित करता हूं कि यह क्लाइंट

2

अधिकतर एप्लिकेशन $_SESSION का उपयोग करते हैं। यदि वहां व्यापक प्रसार कमजोर पड़ता है तो प्रमुख परियोजनाएं अलग-अलग चीजें कर रही होंगी।

1

$ _SESSION में उपयोगकर्ता आईडी संग्रहीत करना एक सामान्य आम अभ्यास है।

आपका विकल्प सत्र के रूप में session_id() का उपयोग करके तालिका में सत्र जानकारी (वर्तमान उपयोगकर्ता आईडी सहित) को स्टोर करने के लिए किया जा सकता है, कुंजी के रूप में।

सत्र की जानकारी सादा पाठ के रूप में संग्रहीत की जाती है।

आपके सेटअप पर निर्भर, सत्र स्थान उचित सेटअप सर्वर पर सुरक्षित होना चाहिए। Session_save_path() के साथ स्थान को बदलना संभव है जो संभावित स्थान के मुद्दों को दूर करेगा।

-2

मैं सत्र में केवल उपयोगकर्ता आईडी जोड़ने के खिलाफ सलाह दूंगा। उदाहरण के लिए:

1: एक ब्राउज़र में खाता बनाएं और लॉग इन करें। फिर उस ब्राउज़र को खोलें और दूसरे कंप्यूटर पर जाएं।

2: उसी खाते में लॉग इन करें और इसे हटाएं। अब एक अलग पासवर्ड के साथ एक नया खाता बनाएं (उसी उपयोगकर्ता नाम के साथ, यदि आईडी के रूप में उपयोग किया जाता है)।

3: अपने अन्य कंप्यूटर पर वापस जाएं और सामान करें। आप पाएंगे कि आप संभवतः अब दूसरे कंप्यूटर पर किए गए खाते का उपयोग कर सकते हैं।

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

तो ऐसा लगता है कि जब आप डेटाबेस से उपयोगकर्ता खाते हटाते हैं, तो संख्यात्मक आईडी का पुन: उपयोग किया जा सकता है (सिस्टम के लगभग 2% मैंने इसे देखा है)। या यदि उपयोगकर्ता आईडी उपयोगकर्ता नाम है (लगभग 20% मैंने यह देखा है)।

तो मैं सत्र में उपयोगकर्ता आईडी और पासवर्ड हैश (i.e md5, sha1) जोड़ने और प्रत्येक बार दोनों का उपयोग करके उपयोगकर्ता की जानकारी प्राप्त करने का सुझाव दूंगा।

+0

के लिए धन्यवाद आपका परिदृश्य तब तक कभी नहीं होना चाहिए जब तक आपके पास एक भयानक प्रोग्रामर आपके लिए काम न करे। – RiceRiceBaby

+0

यदि आपका उपयोगकर्ता आईडी एक ऑटो-वर्धित प्राथमिक कॉलम है (यह क्यों नहीं होगा?) तो यह नहीं होगा .. –

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