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