2011-01-03 12 views
37

मुझे वास्तव में मोंगोडीबी की स्वचालित रूप से जेनरेट की गई आईडी पसंद है। वे वास्तव में उपयोगी हैं।मोंगोडीबी: दस्तावेज़ में "सार्वजनिक रूप से" उपयोग करना सुरक्षित है?

हालांकि, क्या यह उन्हें सार्वजनिक रूप से उपयोग करने के लिए सहेज रहा है?

मान लीजिए कि एक पोस्ट संग्रह है, और/पोस्ट पेज जो आईडी पैरामीटर लेता है (कुछ/पोस्ट/4d901acd8df94c1fe600009b) और इसके बारे में जानकारी प्रदर्शित करता है।

इस तरह उपयोगकर्ता/हैकर दस्तावेज़ की वास्तविक वस्तु आईडी को जानेंगे। क्या यह ठीक है या यह सुरक्षित नहीं है?

धन्यवाद

उत्तर

25

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

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

5

मैं उत्पादन परिवेश में MongoDB के साथ कोई अनुभव नहीं है, तो सत्य के रूप में मेरा उत्तर नहीं लेते हैं, लेकिन मैं कल्पना नहीं कर सकते क्यों यह सुरक्षित नहीं होना चाहिए।

आरडीबीएमएस में एक ऑटो-आईडी प्रकार कॉलम की तुलना करें। आप उन लोगों को हर समय बाहर उजागर करते हैं, मुझे मोंगोडीबी आईडी के साथ ऐसा करने के किसी भी कारण से नहीं पता है।

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

1

यह अब और असुरक्षित नहीं है कि ऑटो वृद्धि आईडी के मूल्य का उपयोग करना माई एसक्यूएल। यह किसी भी तरह से एक सुरक्षा उल्लंघन नहीं है।

3

शायद गोपनीयतासुरक्षा समस्या से अधिक के बारे में सोचें।

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

मुझे लगता है कि दूसरों की सलाह सही मार्ग है: उपयोगकर्ता-विशिष्ट निजी सामग्री के यूआरएल को जानना तक पहुंचने के लिए पर्याप्त नहीं होना चाहिए। एक्सेस करने का प्रयास मिलान करने वाले उपयोगकर्ता को अनुरोध कर रहा है कि जांच करनी चाहिए।

मैं वेब जड़ के बाहर उपयोगकर्ता सामग्री भंडारण, तो एक नया मार्ग/नियंत्रक जो प्रतिक्रिया पार करने से पहले उपयोगकर्ता के बारे में कुछ पहचान संबंधी जानकारी को मान्य होगा के माध्यम से उस तक पहुँच की अनुमति देकर Symfony2 में ऐसा करने का इरादा रखते हैं।

5

मैंने सोचा कि mongodb _id एक डेटास्टैम्प पर आधारित था, और अलग-अलग पते और अन्य चीजें जिन्हें आप निजी रखना पसंद कर सकते हैं।

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

यदि एन्क्रिप्शन कुंजी आंशिक रूप से उपयोगकर्ता या प्रश्न के सत्र के कुछ अद्वितीय गुणों पर आधारित है, तो उपयोगकर्ताओं को सामग्री तक पहुंचने में मुश्किल होती है जब उन्हें नहीं करना चाहिए।

स्पष्ट रूप से उपयोगकर्ता को अन्य माध्यमों से प्रमाणित करना अभी भी महत्वपूर्ण है!

0
  1. यदि आईडी "असूचीबद्ध" सामग्री को लिंक देती है जिसके लिए केवल लिंक की आवश्यकता होती है - यह गोपनीयता समस्या है।

  2. यदि आईडी उपयोगकर्ता लॉगिन के अंतर्गत सामग्री के लिंक प्रदान करती है - कोई समस्या नहीं।

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

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