एक्सपोजिंग डेटाबेस आईडी - सुरक्षा जोखिम?

Question

मैंने सुना है कि डेटाबेस आईडी (उदाहरण के लिए URL) को उजागर करना एक सुरक्षा जोखिम है, लेकिन मुझे यह समझने में परेशानी हो रही है कि क्यों।

किसी भी राय या लिंक पर यह जोखिम क्यों है, या यह क्यों नहीं है?

संपादित करें: यदि आप संसाधन नहीं देख पा रहे हैं, तो निश्चित रूप से पहुँच को बंद foo?id=123कर दिया गया है, आपको एक त्रुटि पृष्ठ मिलेगा। अन्यथा URL स्वयं गुप्त होना चाहिए।

EDIT: यदि URL गुप्त है, तो इसमें संभवतः एक उत्पन्न टोकन होगा, जिसका जीवनकाल सीमित है, उदाहरण के लिए 1 घंटे के लिए मान्य है और केवल एक बार उपयोग किया जा सकता है।

EDIT (महीने बाद): इसके लिए मेरा वर्तमान पसंदीदा अभ्यास आईडी के लिए UUIDS का उपयोग करना और उन्हें उजागर करना है। अगर मैं अनुक्रमिक संख्याओं (आमतौर पर कुछ DBs पर प्रदर्शन के लिए) का उपयोग कर रहा हूं, तो आईडी के रूप में मैं एक वैकल्पिक कुंजी के रूप में प्रत्येक प्रविष्टि के लिए एक UUID टोकन बनाना पसंद करता हूं, और उस का पर्दाफाश करता हूं।

Answer 1

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

यहां कुछ अच्छे नियम दिए गए हैं:

1. किसी ऑपरेशन तक पहुँच को नियंत्रित करने के लिए भूमिका-आधारित सुरक्षा का उपयोग करें। यह कैसे किया जाता है यह आपके द्वारा चुने गए प्लेटफ़ॉर्म और फ्रेमवर्क पर निर्भर करता है, लेकिन कई एक घोषणात्मक सुरक्षा मॉडल का समर्थन करते हैं जो स्वचालित रूप से एक प्रमाणीकरण कदम के लिए ब्राउज़रों को पुनर्निर्देशित करेगा जब किसी कार्रवाई के लिए कुछ प्राधिकरण की आवश्यकता होती है।
2. किसी वस्तु तक पहुंच को नियंत्रित करने के लिए प्रोग्रामेटिक सुरक्षा का उपयोग करें। यह एक फ्रेमवर्क स्तर पर करना कठिन है। अधिक बार, यह कुछ ऐसा है जिसे आपको अपने कोड में लिखना है और इसलिए अधिक त्रुटि प्रवण है। यह जाँच भूमिका-आधारित जाँच से परे जाकर न केवल यह सुनिश्चित करती है कि उपयोगकर्ता के पास संचालन के लिए अधिकार है, बल्कि संशोधित किए जा रहे विशिष्ट वस्तु पर आवश्यक अधिकार भी हैं। भूमिका-आधारित प्रणाली में, यह जांचना आसान है कि केवल प्रबंधक ही उठा सकते हैं, लेकिन इससे परे, आपको यह सुनिश्चित करने की आवश्यकता है कि कर्मचारी विशेष प्रबंधक के विभाग से संबंधित है।
3. अधिकांश डेटाबेस रिकॉर्ड के लिए, स्थिति 1 और 2 पर्याप्त हैं। लेकिन अप्रत्याशित आईडी को जोड़ने पर थोड़ा अतिरिक्त बीमा, या "गहराई से सुरक्षा" के रूप में सोचा जा सकता है, यदि आप उस प्याज में खरीदते हैं। एक जगह जहां अप्रत्याशित पहचानकर्ता एक आवश्यकता है, हालांकि, सत्र आईडी या अन्य प्रमाणीकरण टोकन में है, जहां आईडी स्वयं एक अनुरोध को प्रमाणित करता है। इन्हें क्रिप्टोग्राफिक RNG द्वारा जनरेट किया जाना चाहिए।

Comments

IMO, अप्रत्याशित आईडी जोड़ना "अस्पष्टता के माध्यम से सुरक्षा" दृष्टिकोण है और सुरक्षा की झूठी भावना पैदा कर सकता है। (1) और (2) पर ध्यान केंद्रित करना बेहतर है और सुनिश्चित करें कि आपका अभिगम नियंत्रण ठोस है।

— stucampbell

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

— एरिक्सन

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

— user247702

@ आप वास्तव में यह नहीं कह सकते हैं कि मेरे पास कितने ग्राहक हैं, इसका खुलासा करने के लिए "मैं वास्तव में नहीं चाहता"। मेरा मतलब है कि मैकडॉनल्ड्स का एक बड़ा संकेत यह है कि उन्होंने 10 बिलियन हैम्बर्गर की सेवा की है। यह एक सुरक्षा जोखिम नहीं है, यह एक प्राथमिकता है। इसके अलावा, आपको सबसे अधिक एप्लिकेशन में किसी भी URL को देखने से पहले लॉगिन करना होगा, जहां हम इस बारे में चिंता करेंगे। इसलिए हमें पता होगा कि कौन डेटा स्क्रैप कर रहा था।

— वेन ब्लास

एक बात जो मैंने इस बातचीत में नहीं देखी है, वह यह है कि समस्या निवारण और उपयोग में आसान दृष्टिकोण से, किसी विशेष संसाधन में सीधे उपयोगकर्ताओं की मदद करने के लिए url में ID का खुलासा होना बहुत आसान हो सकता है या उन्हें सक्षम करने में सक्षम है आपको यह बताने के लिए कि वे किस संसाधन को देख रहे हैं। आप केवल एक विचार प्रस्तुत करने के लिए, उच्च मूल्य पर ऑटो वेतन वृद्धि शुरू करके व्यावसायिक खुफिया चिंताओं से बच सकते हैं।

— चोकोमोंकी जूल

Answer 2

जबकि डेटा सुरक्षा जोखिम नहीं है, यह बिल्कुल व्यावसायिक खुफिया सुरक्षा जोखिम है क्योंकि यह डेटा आकार और वेग दोनों को उजागर करता है। मैंने देखा है कि व्यवसायों को इससे नुकसान पहुंचा है और इस विरोधी पैटर्न के बारे में गहराई से लिखा है। जब तक आप सिर्फ एक प्रयोग कर रहे हैं और एक व्यवसाय नहीं है, मैं आपके निजी आईडी को सार्वजनिक नज़र से बाहर रखने का सुझाव दूंगा। https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Comments

अंत में, सुरक्षा जोखिम के अलावा अन्य पहलुओं को लाने वाला सनी उत्तर।

— peceps 13

यह स्वीकृत उत्तर होना चाहिए। यदि आप मानते हैं कि हमलावर आपकी सुरक्षा को दरकिनार कर सकता है (जो आपको हमेशा करना चाहिए), तो आप इस तरह की जानकारी को हाथ नहीं लगाना चाहते।

— क्रिल्ल

@ क्रिल उन्हें आपकी सुरक्षा को बायपास करने की भी आवश्यकता नहीं है। उन्हें बस एक खाता बनाने की आवश्यकता है!

— पीटर

Answer 3

यह इस बात पर निर्भर करता है कि आईडी किस लिए खड़ी हैं।

उस साइट पर विचार करें, जो प्रतिस्पर्धी कारणों से सार्वजनिक नहीं करना चाहती कि उनके पास कितने सदस्य हैं, लेकिन अनुक्रमिक आईडी का उपयोग करके इसे URL में वैसे भी प्रकट किया जाता है: http://some.domain.name/user?id=3933

दूसरी ओर, अगर वे इसके बजाय उपयोगकर्ता के लॉगिन नाम का उपयोग करते हैं: http://some.domain.name/user?id=some उन्होंने ऐसा कुछ भी नहीं बताया है जिसे उपयोगकर्ता पहले से ही नहीं जानता था।

Comments

आप अनुक्रमिक आईडी आप रहे हों तो सही उपयोग कर रहे हैं, लेकिन अगर नहीं तो कुछ भी खुलासा नहीं करता है कि

— orip

@orip: जैसा मैंने कहा, यह इस बात पर निर्भर करता है कि कोई व्यक्ति कई आईडी की जांच करके क्या खोज सकता है। क्या कोई पैटर्न है? क्या वे उस जानकारी का उपयोग उस जानकारी को प्राप्त करने के लिए कर सकते हैं जो उनके पास नहीं है?

— कुछ

@ जॉन: संपादन के लिए धन्यवाद। अंग्रेजी मेरी मूल भाषा नहीं है :)

— कुछ 15

मैंने ठीक यही किया है: एक प्रतियोगी के उपयोगकर्ता नाम के आकार को निर्धारित करने के लिए अनुक्रमिक आईडी संख्याओं का उपयोग किया।

— मीका

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

— कुछ

Answer 4

सामान्य विचार इन पंक्तियों के साथ जाता है: "अपने ऐप के आंतरिक कामकाज के बारे में किसी को भी कम जानकारी दें।"

कुछ जानकारी का खुलासा करने के रूप में डेटाबेस आईडी को उजागर करना मायने रखता है।

इसका कारण यह है कि हैकर्स आप पर हमला करने के लिए आपके ऐप्स के आंतरिक कामकाज के बारे में किसी भी जानकारी का उपयोग कर सकते हैं, या कोई उपयोगकर्ता URL को डेटाबेस में बदलने के लिए बदल सकता है / वह देखने के लिए नहीं है?

Comments

उन संसाधनों तक पहुँचना जिन्हें वे देखने वाले नहीं हैं - केवल अगर मैं अनुमतियों की जाँच नहीं करता (जो मैं करता हूँ, अन्यथा मुझे एक अलग सुरक्षा समस्या है)। "आंतरिक कामकाज" के बारे में जानकारी का खुलासा करना - यही मेरा सवाल है। यह एक समस्या क्यों है?

— ओरीप

@orip: यह सब संभव के रूप में सुरक्षित होने के बारे में है। यदि आप प्रोग्रामर की तरह हैं जो गलतियाँ नहीं करते हैं, तो यह कोई समस्या नहीं है। अन्यथा, कम विवरणों को उजागर करना आपके कोड का शोषण करने के लिए और अधिक कठिन बना देता है यदि (जब) ​​आप गलतियाँ करते हैं। अपने आप से, आप सही हैं, यह सुरक्षा नहीं जोड़ता है।

— एडम बेलाएरे

@ अदम: सतही सुरक्षा बिना सुरक्षा से भी बदतर हो सकती है। बिना किसी सुरक्षा के आप स्पष्ट हैं, सतही सुरक्षा के साथ आप सोच सकते हैं कि यह कुछ गैर-नगण्य है।

— 1

Answer 5

हम डेटाबेस आईडी के लिए GUIDs का उपयोग करते हैं। उन्हें लीक करना बहुत कम खतरनाक है।

Comments

यह वही है जो मैं सुझाव दूंगा। आपके डेटाबेस में GUID का अनुमान लगाने की बहुत कम संभावना है।

— जॉन एरिकसन

यह एक प्रदर्शन दंड के रूप में आता है। यहाँ

— जेशुरुन

दिलचस्प बात यह है कि 1 गाइड का उपयोग करने के बारे में है कि आप ग्राहकों को डेटाबेस आईडी उत्पन्न कर सकते हैं। दिलचस्प बात 2 यह है कि उन्हें शार्ल्ड डेटाबेस के साथ कोई समस्या नहीं है जिस तरह से ऑटो इंक्रीमेंटिंग आईडी करते हैं।

— ब्रायन व्हाइट

क्या आप उपयोगकर्ताओं, टिप्पणियों, पोस्टों की पहचान करने के लिए आईडी विशेषताओं के रूप में HTML कोड में भी इन GUID का उपयोग करते हैं? यह दर्शाने के लिए कि उपयोगकर्ता किस लिंक पर क्लिक करता है या वह कौन सा पोस्ट करना चाहता है?

— त्रिकज़ी

Answer 6

यदि आप अपने db में पूर्णांक आईडी का उपयोग कर रहे हैं, तो आप उपयोगकर्ताओं के लिए यह देखना आसान बना सकते हैं कि वे qs चर बदलकर डेटा न देखें।

उदाहरण के लिए, एक उपयोगकर्ता इस qs में आसानी से आईडी पैरामीटर बदल सकता है और डेटा को देख सकता है / संशोधित कर सकता है जो उन्हें http: // someurl? Id = नहीं करना चाहिए।

Comments

यदि मैं अनुमतियों की जांच नहीं करता हूं तो मुझे एक अलग सुरक्षा समस्या है।

— ओरीप

लेकिन उत्तर सटीक है: "हो सकता है"

— सीन ओसेवा

सवाल यह नहीं है कि क्या आप अनुमति की जाँच करेंगे। यदि आपको पता नहीं है कि नया भाड़ा अनुमतियों की जांच करेगा।

— ब्रायन व्हाइट

@BrianWhite - यही कारण है कि आप एक कोड समीक्षा प्रक्रिया चाहते हैं, ताकि उत्पादन शुरू होने से पहले आप उन्हें शिक्षित कर सकें।

— कैंडू

URL या फॉर्म चर में प्रयोग होने पर हम पूर्णांक आईडी को एन्क्रिप्ट करते हैं।

— ब्रायन व्हाइट

Answer 7

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

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

इसलिए हम सिंथेटिक सत्र लोकल आईडी का उपयोग करते हैं क्योंकि यह उतना ही छुपाता है जितना हम दूर हो सकते हैं।

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

Comments

दिलचस्प है, हालांकि मुझे लगता है कि हर अनुरोध के लिए सभी इनपुट (URL पैरामीटर सहित) की जाँच करना वेब के लिए बहुत उपयुक्त है।

— ६