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


23

मैंने लोगों को इंटरनेट पर यहां और वहां व्याख्यान देते हुए सुना है कि वेब एप्लिकेशन में सार्वजनिक सामना करने वाले डेटाबेस आईडी को अस्पष्ट करना सबसे अच्छा अभ्यास है। मुझे लगता है कि वे मुख्य रूप से रूपों और urls में मतलब रखते हैं, लेकिन मैंने इस विषय पर एक कौर से ज्यादा कुछ नहीं पढ़ा है।

संपादित करें : बेशक, अब जब मैं यह पूछता हूं, तो मुझे इस विषय पर कुछ संसाधन मिलते हैं:

इन कड़ियों ने मेरी कुछ जिज्ञासाओं को पूरा किया, लेकिन एसओ पदों के पास कई वोट नहीं हैं और जरूरी नहीं कि वे इस संदर्भ में विषय के आसपास केंद्रित हों, इसलिए मुझे यकीन नहीं है कि इसका क्या बनाना है, और उनमें से कुछ का दावा है कि तीसरा लिंक फर्जी है। मैं अपनी बाकी पोस्ट को बरकरार रखूंगा:


मैं अस्पष्टता और सुरक्षा के बीच के अंतर को समझता हूं, साथ ही साथ दोनों कैसे एक साथ काम कर सकते हैं, लेकिन मैं कल्पना नहीं कर सकता कि यह क्यों आवश्यक होगा।

क्या इसमें कोई सच्चाई है, क्या यह सिर्फ व्यामोह है, या यह पूरी तरह से पूरी तरह से फर्जी है?

मैं इसे करने के तरीकों के बारे में सोच सकता हूं, लेकिन निश्चित रूप से यह एप्लिकेशन कोड में बहुत अधिक जटिलता जोड़ता है। यह किन परिस्थितियों में उपयोगी होगा? इस तो है कुछ लोग अक्सर करते हैं, कैसे यह आम तौर पर तैनात किया जाता है? पहचानकर्ताओं को परेशान करना? कुछ और? यह बहुत अधिक अतिरिक्त सुरक्षा के लिए बहुत काम की तरह लगता है। मैं वास्तविक समाधानों की तलाश में नहीं हूं, मैं सिर्फ यह जानना चाहता हूं कि वास्तविक दुनिया में लोग ऐसा कैसे / क्यों करेंगे।

क्या यह वास्तव में एक "सर्वोत्तम अभ्यास" माना जाता है या यह केवल थोड़े मूल्य का सूक्ष्म अनुकूलन है?

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

जवाबों:


28

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

उदाहरण के लिए, यदि आप क्रमबद्ध तरीके से उत्पन्न एक आदेश आईडी को उजागर करने वाले थे, और आपके पास एक सामाजिक इंजीनियरिंग हमला था, जिसमें ग्राहक सहायता के लिए फोन किया गया था और कहा गया था, "हे, मैंने अभी एक नए कंप्यूटर पर $ 2000 खर्च किए हैं और आप लोगों ने मुझे किसी अन्य व्यक्ति के आदेश के लिए भेजा है एक $ 15 केबल, अब मैं $ 2000 बाहर हूँ "आप बहुत समय बिता सकते हैं इससे पहले कि आप यह निष्कर्ष निकालें कि आप फर्जी हैं या आप एक नया कंप्यूटर भेजते हैं।"

समान, कम परिष्कृत, लेकिन विषय पर शर्मनाक विविधताएं हैं; यदि एक बुरा आदमी एक ऑर्डर आईडी को एक रसीद के लिए एक ईमेल लिंक को बढ़ाता है, और अगर कोई अतिरिक्त सत्यापन यह सत्यापित करने के लिए नहीं किया जाता है कि लिंक पर क्लिक करने वाले व्यक्ति को आदेश आईडी देखने का अधिकार है, तो आप अनजाने में निजी ग्राहक जानकारी को उजागर कर रहे हैं गलत व्यक्ति के लिए।

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

मैं कहूंगा कि इस स्थगन को "सर्वोत्तम अभ्यास" कहना एक खिंचाव है, लेकिन कुछ परिदृश्यों में, यह आपके सत्यापन या प्राधिकरण कोड में एक और कमजोरी का फायदा उठाने में आसानी को कम कर सकता है। दूसरी ओर, यह वास्तव में मायने नहीं रखता है कि क्या कोई जानता है कि आपने ब्लॉग पोस्ट # 1 या # 2559 लिखा है। यदि अतिरिक्त जानकारी के साथ भी आईडी बहुमूल्य जानकारी नहीं है, तो यह तर्क कि इसे सबसे अच्छा अभ्यास है, कम वजन रखता है।

एक दूसरा संभावित तर्क है, जो यह है कि आपका डेटाबेस पहचानकर्ता आपको एक विशेष डेटाबेस कार्यान्वयन (या उदाहरण) के लिए भेज सकता है, और जब आपकी कंपनी एक प्रतियोगी को खरीद लेती है या उठाती है और अब आपको दो विरासत प्रणालियों, या सीईओ का विलय करना होगा DynoCoreBase के प्रतिनिधि के साथ शराब पीकर बाहर जाता है और वे तय करते हैं कि अब आप अपना सारा डेटा DynoCoreBase संस्करण 13h में स्थानांतरित कर देंगे और यह चाहता है कि सभी प्राथमिक कुंजियाँ मार्गदर्शक हों, और आपको पुरानी IDs को नए में अनुवाद करने के लिए किसी प्रकार की मैपिंग परत बनानी होगी। आईडी ताकि पुराने URL टूट न जाएं, लेकिन क्या ये परिदृश्य आपके लिए किसी सामान्य सर्वोत्तम अभ्यास की तुलना में आपके व्यवसाय की प्रकृति (और उन आईडी के साथ ग्राहक की भागीदारी) पर अधिक निर्भर करते हैं।


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

9

यह मेरा इस पर लेना है:

जबकि "अस्पष्टता के माध्यम से सुरक्षा" स्पष्ट रूप से पर्याप्त नहीं है, अस्पष्टता सुरक्षा की सहायता कर सकती है, भले ही बस थोड़ा सा। आपको यह तय करना होगा कि आपके आवेदन में कुछ इस तरह से तैनात करने के लिए अतिरिक्त प्रयास के लायक है या नहीं।

सुरक्षा के बाहर एक और कारण है जिसे मैं इसे लागू करने के बारे में सोच सकता हूं:

एकांत

मान लीजिए कि हम url में उपयोगकर्ता आईडी के साथ काम कर रहे हैं। यदि जो का यूजर आईडी है 100और बॉब का यूजर आईडी है 101, तो यह संभवत: स्पष्ट है कि जो का खाता पहले बनाया गया था। हालांकि यह अधिकांश अनुप्रयोगों में मायने नहीं रखता है, यह कुछ के लिए मायने रख सकता है। यह अस्पष्टता के माध्यम से सख्ती से गोपनीयता का एक उदाहरण है , इसलिए जब तक आपके पास उपयोगकर्ता आईडी को बाधित करने की एक बहुत ही परिष्कृत प्रणाली नहीं है, तब तक यह आसान हो सकता है कि यह भंग करने और यह पता लगाने के लिए पर्याप्त हो कि आईडी 3Js9kW3hTs7sa120वाले उपयोगकर्ता का आईडी के साथ उपयोगकर्ता की तुलना में लंबा खाता है Q8Hs73kks0hEg

से लिंक मैं संदर्भित:

पहला यह है कि किसी ऑब्जेक्ट के लिए URL दिया गया है, आप उन ऑब्जेक्ट्स के लिए URL पता कर सकते हैं जो इसके आसपास बनाए गए थे। यह आपके डेटाबेस में संभावित प्रतियोगियों या अन्य ऐसे लोगों की संख्या को उजागर करता है जिन्हें आप यह जानकारी नहीं देना चाहते हैं (जैसा कि सहयोगी ने जर्मन टैंक उत्पादन स्तरों का अनुमान लगाकर क्रमिक संख्याओं को देखते हुए प्रदर्शित किया है।)

ऑटो-इन्क्रीमेंट आईडी का उपयोग सार्वजनिक रूप से डेटाबेस में वस्तुओं की संख्या को उजागर करता है, और यह उजागर कर सकता है कि कौन से पहले बनाए गए थे और कौन से नए हैं। यह जानकारी इस तथ्य को दूर कर सकती है कि एक व्यवसाय नया है, या यहां तक ​​कि अच्छा भी नहीं कर रहा है। उदाहरण के लिए: मान लीजिए कि आप एक पुस्तक का ऑर्डर करते हैं और आपकी ऑर्डर आईडी है 1। यह स्पष्ट हो सकता है कि आपका आदेश सिस्टम में पहला था, जो कि अनावश्यक हो सकता है। मान लीजिए कि आप वापस जाते हैं और दूसरी ऑर्डर करते हैं और आपकी ऑर्डर आईडी है 9। इससे यह जानकारी मिलती है कि आपके दो आदेशों के बीच केवल 7 आदेशों को समय सीमा में रखा गया था। यह प्रतियोगियों के लिए बहुमूल्य जानकारी हो सकती है। इस मामले में, संख्यात्मक ऑटो-इंक्रीमेंट आईडी संभवतया बेहतर नहीं है।


2

"अस्पष्ट" शब्द शायद यहाँ थोड़ा भ्रामक है, और, लोगों को "मोटे तौर पर" या "आंशिक रूप से छिपाने" के लिए प्रेरित कर सकता है।

अनुशंसा यह है कि यदि आपने कभी भी किसी डेटाबेस में कोई संवेदनशील डेटा शामिल है, तो उसे सार्वजनिक URL के हिस्से के रूप में आंतरिक रूप से जेनरेट की गई डेटाबेस कुंजी में शामिल नहीं किया है।

इसका सिर्फ URL में संख्याओं के साथ खेलना और अन्य रिकॉर्ड तक पहुंचना बहुत आसान है।


1
हाँ, मेरा मतलब था कि शीर्षक और कुछ अन्य उदाहरणों में मोटे तौर पर - इस बारे में खेद है। खुशी है कि आप जानते हैं कि मेरा क्या मतलब था। मुझे "नंबरों के साथ खेलने" के बारे में बात मिलती है, लेकिन यह मेरी तरह है - आपकी ऐप को आपकी उंगलियों का अनुमान लगाने और उन्हें पार करने के लिए आईडी को थोड़ा मुश्किल बनाकर संरक्षित नहीं किया जाना चाहिए। यदि कोई व्यक्ति भूमि पर जाता है /account/8hdy39s1lks062dfasd4और वह वास्तविक खाते में मैप करता है, तो उन्हें किसी भी रास्ते तक पहुंच नहीं होनी चाहिए।
वेस्ले मर्च

2

मैं मुख्यधारा के खिलाफ जाऊंगा, और आपको बताऊंगा कि एक यादृच्छिक, लंबे पहचानकर्ता का उपयोग करना मेरी राय में सुरक्षा का एक अच्छा सभ्य रूप है।

यह स्पष्ट किया जाना चाहिए कि जिस किसी के पास उस डेटा तक पहुंच है, वह पासवर्ड जितना संवेदनशील है। और निश्चित रूप से इसका नुकसान यह है कि अगर यह जंगली में चला जाता है तो इसे बदलना कठिन हो सकता है।

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

बेशक, सुरक्षा की जितनी अधिक परतें हैं, उतना बेहतर है। लेकिन यह विधि अकेले एक जोड़े की तुलना में अधिक सुरक्षित हो सकती है।


1
मैं सहमत हूँ। सुरक्षा की जो भी विधि आप उपयोग कर रहे हैं, वह तार के ऊपर गैर-अनुमानित बाइट्स भेजने के लिए नीचे आती है। यदि सही तरीके से किया जाता है, तो आप एक आईडी भेज रहे हैं जो एन्क्रिप्टेड के रूप में अच्छा है, जो आपके आईडी स्थान के बारे में कोई भी जानकारी लीक नहीं करता है, और मैं तर्क दूंगा कि जो लोग बात कर रहे हैं उससे अधिक मजबूत है जब वे अस्पष्टता के माध्यम से सुरक्षा पैन करते हैं। "
मार्क स्ट्रोब

0

इसके दो पहलू हैं: प्रयोज्य और सुरक्षा।

सुरक्षा-वार, अस्पष्ट आईडी के बजाय व्यर्थ है; यह महत्वपूर्ण है कि आईडी किसी भी गैर-सार्वजनिक संसाधन के लिए केवल 'कुंजी' नहीं होनी चाहिए। इसका मतलब है कि यदि आप चयनित उपयोगकर्ताओं को एक निश्चित पृष्ठ तक पहुंच देना चाहते हैं, तो URL में पृष्ठ की आईडी की आवश्यकता नहीं है, आपको एक वास्तविक सुरक्षा तंत्र जैसे कि उपयोगकर्ता नाम / पासवर्ड लॉगिन या सार्वजनिक / निजी कुंजी प्रमाणीकरण लागू करना होगा, साथ ही उचित प्राधिकरण (यानी, सिस्टम को प्रति मामले के आधार पर न्याय करने में सक्षम होना चाहिए कि क्या उपयोगकर्ता X को संसाधन Y तक पहुंचने की अनुमति है, और तदनुसार कार्य करें)।

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


एक वेब ऐप में मैं उन उदाहरणों के बारे में नहीं सोच सकता, जहां लोग किसी भी कारण से आंतरिक आईडी लिखेंगे। किसी URL या किसी चीज़ को ईमेल करना (या किसी को बुकमार्क करना) जिसमें एक आईडी है जिसे मैं समझ सकता हूं, लेकिन उस स्थिति में मैं यह नहीं देखता कि उपयोगिता कहां से आती है। मैंने उन्हें मध्य-धारा बदलने का सुझाव नहीं दिया, लेकिन मैं आपकी बात लेता हूं कि यह एक मुद्दा कैसे होगा।
वेस्ले मर्च

@Madmartigan: यह कस्टम सूचना प्रणाली के साथ इतना असामान्य नहीं है। उपयोगकर्ताओं को कुछ चीजें करने की आवश्यकता होती है, और कभी-कभी एप्लिकेशन उन्हें सीधे समर्थन नहीं देता है, या यह सीधे टूट गया है, या हो सकता है कि आईडी के माध्यम से सीधे जाकर सॉफ्टवेयर आर्किटेक्ट की कल्पना करने वाले मार्ग पर जाना आसान हो। लोग इन चीजों के साथ बहुत रचनात्मक हो सकते हैं, और इससे पहले कि आप जानते हैं, उन 'आंतरिक' आईडी की शुरुआत अपने स्वयं के जीवन का नेतृत्व कर रही है।
तदमर्स

0

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

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

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


2
मुझे लगता है कि आप गलत विचार प्राप्त कर सकते हैं, मैंने सुझाव दिया कि "केवल उनकी आंतरिक आईडी को जानकर मनमाना संसाधनों तक पहुंच की अनुमति नहीं है", मैं मौजूदा सुरक्षा उपायों के शीर्ष पर आईडी को बाधित करने के बारे में बात कर रहा हूं। जाहिर है, सिर्फ आईडी या हैश को जानने को ही प्राधिकरण नहीं माना जाना चाहिए।
वेस्ले मर्च

0

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

आईडी से पहले और बाद में मूल्य पर एक MD5 कर नमक (यादृच्छिक अक्षरों का एक सेट संग्रह) जोड़कर चेकसम उत्पन्न करें।

आईडी मान पढ़ने वाले प्रत्येक पृष्ठ पर इसे चेकसम मान उत्पन्न करना चाहिए और इसे पास किए गए के साथ तुलना करना चाहिए, अगर यह मेल नहीं खाता है तो अनुरोध से इनकार करें।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.