मूल रूप से 5 मार्च, 2019 को प्रकाशित
यदि आप एक एप्लिकेशन डेवलपर, डेटाबेस एडमिनिस्ट्रेटर (DBA), या किसी भी प्रकार के टेक्नोलॉजिस्ट हैं, तो कोड इंजेक्शन आपके रडार पर होना चाहिए।
आपके पास एक सुरक्षित क्लाउड वातावरण है। आपके पास डेटाबेस एक्सेस लॉक्ड डाउन है। लेकिन आपके एप्लिकेशन कोड का क्या? हालांकि इसे अधिक सुरक्षित माना जाता है, NoSQLi में नहीं का मतलब यह नहीं है कि यह अन-इंजेक्टेबल है! NoSQL किसी भी अन्य डेटाबेस कोड की तरह ही कोड इंजेक्शन के प्रति संवेदनशील हो सकता है। कोड इंजेक्शन के खिलाफ सुरक्षा न करना अपने दरवाजों के लिए सुरक्षा प्रणाली लगाने और एक पिछली खिड़की खुली छोड़ने जैसा है।
कोड इंजेक्शन क्या है?
कोड इंजेक्शन केवल असत्यापित डेटा का एक कमजोर प्रोग्राम में इंजेक्ट (या जोड़ा) जाना है जहां यह एप्लिकेशन कोड के रूप में निष्पादित होता है, अक्सर विनाशकारी परिणामों के साथ।
SQLi इंजेक्शन के सबसे सामान्य प्रकारों में से एक है और, एक दशक से अधिक पुराना होने के बावजूद, अभी भी मजबूत है। इंजेक्शन मुद्दे केवल डेटाबेस भाषाओं तक सीमित नहीं हैं। SQL और NoSQL से परे, इंजेक्शन XPath®, XML पार्सर्स, SMTP हेडर्स, और अन्य संदर्भों में हो सकता है। जहां तक गंभीरता का सवाल है, कोड इंजेक्शन रिमोट कोड एक्जीक्यूशन (RCE) के समान है - पेनिट्रेशन टेस्टिंग का गेम ओवर स्क्रीन।
अपने एप्लिकेशन में NoSQLi का पता लगाना और रोकना महत्वपूर्ण है। एक अनियंत्रित इंजेक्शन वेक्टर को अनुमति देना आपके उपयोगकर्ता आधार की सुरक्षा को खतरे में डाल सकता है, जो विश्वास की संभावित व्यवसाय-समाप्ति हानि का प्रतिनिधित्व करता है। सौभाग्य से, यांत्रिकी को समझने के बाद, आप अपनी सेवाओं में NoSQLi कमजोरियों का पता लगाने और रोकने के लिए ठोस कदम उठा सकते हैं।
सरल NoSQLi उदाहरण
आमतौर पर, MongoDB® एक सुरक्षित BSON क्वेरी निर्माण उपकरण का उपयोग करके निर्मित बाइनरी JSON (BSON) डेटा को ग्रहण करता है। लेकिन कुछ मामलों में, MongoDB अनसीरियलाइज़्ड JSON और जावास्क्रिप्ट (JS) एक्सप्रेशन भी स्वीकार कर सकता है, जैसे $where ऑपरेटर। SQL की तरह, $where ऑपरेटर NoSQL में संभावित इंजेक्शन के लिए प्रवण है। हालांकि, SQL के विपरीत, NoSQL $where अपनी शर्त को JS में व्यक्त करता है। इसका मतलब है कि यह SQL द्वारा प्रदान की जाने वाली सीमाओं के बजाय JS की पूरी अभिव्यंजक शक्ति का उपयोग करके संभावित इंजेक्शन क्वेरी तैयार कर सकता है।
सार्वजनिक रिपॉजिटरी में MongoDB इंजेक्शन स्ट्रिंग्स की सूचियों को देखने से कुछ सामान्य इंजेक्शन रणनीतियों का पता चलता है, जो SQL और अन्य भाषाओं में समान कमजोरियों के समानांतर हैं। उदाहरण के लिए, कुछ छिपे हुए (या एडमिन-स्तर) संसाधनों और विशेषाधिकारों को पढ़ने के प्रयास में क्वेरी को सही मान वापस करने के लिए मजबूर करने के लिए क्लासिक 1 == 1 एक्सप्रेशन का उपयोग करते हैं:
$Where: '1 == 1' अन्य स्निपेट्स sleep() फ़ंक्शन का उपयोग करके DB को धीमा करके और एक साइड-इफेक्ट बनाकर एक ब्लाइंड इंजेक्शन रणनीति का अनुकरण करते हैं जो - चतुराई से डिज़ाइन किए गए फिल्टर्स के साथ मिलकर - संवेदनशील जानकारी को गिन सकता है:
';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000); और फिर निश्चित रूप से सादा पुराना डेटा एक्सफिल्ट्रेशन है, जहां इंजेक्ट की गई क्वेरी सीधे महत्वपूर्ण जानकारी से मिलान करने और पुनर्प्राप्त करने का प्रयास कर रही है।
' && this.password.match(/.*/)//+%00 पहले उदाहरण के बाद, शेष दो $where ऑपरेटर का उपयोग नहीं करते हैं। NoSQL DB पर हमला करने के लिए आपको JS-फ्लेवर्ड एक्सप्रेशन की आवश्यकता नहीं है।
NoSQLi को रोकना
NoSQLi-प्रतिरोधी एप्लिकेशन आर्किटेक्चर बनाने का प्रयास करते समय कई सामान्य रणनीतियां अपनाई जा सकती हैं। यह कोई आश्चर्य की बात नहीं है कि वे सामान्य एंटी-इंजेक्शन सलाह के अनुरूप हैं।
MongoDB / NoSQLi कोई अपवाद नहीं है
कुछ लोग कोड इंजेक्शन को SQL-विशिष्ट मानते हैं और अन्य संदर्भों पर लागू इंजेक्शन सिद्धांतों की वैधता को कम आंकते हैं। उम्मीद है, यह पोस्ट आपको समझाएगा कि NoSQLi वास्तविक है। यह "MongoDB will not prevent NoSQL injections in your Node.js app" जैसी पोस्ट में अच्छी तरह से प्रलेखित है।
असत्यापित उपयोगकर्ता डेटा पर भरोसा न करें
सुरक्षा कारणों से, आपको उपयोगकर्ताओं पर भरोसा नहीं करना चाहिए!
यह सुरक्षा में क्लिच लग सकता है, लेकिन हर इनपुट को दुर्भावनापूर्ण इरादे से जांचा जाने की उम्मीद करें। हमारा पहले का $where उदाहरण स्पष्ट रूप से दर्शाता है कि हम $where: unvalidated_input जैसा कुछ क्यों नहीं कर सकते - हम सोच सकते हैं कि हम इस बिंदु पर उपयोगकर्ता को फ़िल्टर उजागर कर रहे हैं (वैसे भी बुरा!)। तथ्य यह है कि उपयोगकर्ता बड़ी क्वेरी में असत्यापित डेटा पेश कर रहे हैं, यह सर्वोत्तम अभ्यास से बहुत दूर है।
भाषा या इंटीग्रेशन-विशिष्टताओं से सावधान रहें
भले ही NoSQLi इंजेक्शन के प्रति प्रतिरक्षित होने के मामले में विशेष नहीं है (और कई समान प्रकार के हमलों से ग्रस्त है), इसका मतलब यह नहीं है कि NoSQLi के लिए विशिष्ट रणनीतियाँ भी नहीं हैं - या यहां तक कि NoSQL DB के शीर्ष पर बनी भाषाओं या घटकों के लिए भी। एक प्रमुख उदाहरण यह है कि चूंकि $where एक तरह से फॉर्मेट किया गया है जो PHP वेरिएबल के रूप में पास होता है, NoSQL DB जो PHP एप्लिकेशन के शीर्ष पर बना है, उसे इसके लिए जिम्मेदार होना होगा और $where में संग्रहीत दुर्भावनापूर्ण स्ट्रिंग इंजेक्शन के संभावित परिदृश्य के लिए भी।
निष्कर्ष
फिर से, NoSQLi में नहीं का मतलब अन-इंजेक्टेबल नहीं है! NoSQL, SQL, SMTP हेडर्स, XML, और अन्य संदर्भों की तरह, कोड इंजेक्शन और सामान्य चीजों-को-एप्लिकेशन-कोड-के-रूप-में-मानने-जो-नहीं-हैं के नुकसान के प्रति समान रूप से संवेदनशील है जो कई अन्य तकनीकों को परेशान करते हैं।
उम्मीद है, इस पोस्ट ने आपको NoSQLi की बेहतर समझ प्रदान की है और इसका आपके व्यवसाय के लिए क्या अर्थ है। अब, आप अपने कोड को उन प्रक्रियाओं की ओर मोड़ सकते हैं जो इसे कम प्रचलित, कम व्यापक और कम प्रभावशाली बनाती हैं। यदि आपको यह सुनिश्चित करने के लिए कुछ MongoDB प्रबंधन सलाह की आवश्यकता है कि आपका ऐप और होस्टिंग वातावरण सुरक्षित है, तो रैकस्पेस ObjectRocket के पास अनुभवी DBA हैं जो मदद कर सकते हैं।
रैकस्पेस DBA सेवाओं के बारे में और जानें।
किसी भी टिप्पणी या प्रश्न के लिए फीडबैक टैब का उपयोग करें। आप सेल्स चैट पर क्लिक करके अभी चैट कर सकते हैं और बातचीत शुरू कर सकते हैं।
