मुख्य सामग्री पर जाएं

MongoDB में SQL/NoSQL इंजेक्शन हमलों की रोकथाम

इनपुट वैलिडेट करके, क्वेरी सुरक्षित करके, और डिफेंस-इन-डेप्थ अपनाकर NoSQL इंजेक्शन से MongoDB को सुरक्षित रखें। इस गाइड में हमले के पैटर्न और उनकी रोकथाम जानें।
अपडेट किया गया 25 सित॰ 2026  · 6 मि॰ पढ़ें

AI के साथ खोजें

ChatGPTClaudePerplexity

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

NoSQL इंजेक्शन क्या है?

NoSQL इंजेक्शन तब होता है जब हमलावर अपर्याप्त रूप से वैलिडेट किए गए उपयोगकर्ता इनपुट का दुरुपयोग करके डेटाबेस क्वेरी लॉजिक में हेरफेर करते हैं। दुर्भावनापूर्ण पेलोड इंजेक्ट करके, हमलावर ऑथेंटिकेशन मैकेनिज़्म को बायपास कर सकते हैं, अनधिकृत डेटा निकाल सकते हैं, या एप्लिकेशन की सुरक्षा नियंत्रणों को दरकिनार कर सकते हैं।

SQL इंजेक्शन के विपरीत, जो स्ट्रिंग-आधारित क्वेरी निर्माण की कमजोरियों का फायदा उठाता है, NoSQL इंजेक्शन लचीली डेटा संरचनाओं और डायनेमिक क्वेरियों का लाभ उठाता है। यह विशेष रूप से खतरनाक है जब एप्लिकेशन interface{} या map[string]interface{} जैसे ढीले-टाइप्ड इनपुट बिना उचित वैलिडेशन के स्वीकार करते हैं।

MongoDB क्यों अलग है

MongoDB क्वेरियाँ BSON (बाइनरी JSON) ऑब्जेक्ट्स—संरचित की-वैल्यू पेयर्स—का उपयोग करके बनाई जाती हैं, कच्ची स्ट्रिंग्स के बजाय। यह डिज़ाइन कई पारंपरिक इंजेक्शन जोखिमों से बचता है क्योंकि क्वेरियाँ स्ट्रिंग कॉनकैटनेशन के जरिए असेंबल नहीं होतीं।

हालाँकि, यदि उपयोगकर्ता इनपुट को उचित वैलिडेशन के बिना सीधे इन BSON ऑब्जेक्ट्स में एम्बेड किया जाता है, तो हमलावर $ne, $gt या $or जैसे MongoDB ऑपरेटर इंजेक्ट कर सकते हैं और क्वेरी के लॉजिक को बदल सकते हैं।

उदाहरण: Go में ऑपरेटर इंजेक्शन

filter := bson.M{"name": inputName}
collection.Find(ctx, filter)

यदि inputName एक साधारण स्ट्रिंग है जैसे "Joe", तो यह सुरक्षित है। लेकिन यदि आपका कोड map[string]interface{} या रॉ JSON की अनुमति देता है, तो एक हमलावर निम्न जैसे ऑपरेटर ऑब्जेक्ट्स इंजेक्ट कर सकता है:

{ "$ne": null }

यह पेलोड क्वेरी लॉजिक को बदल देता है और किसी विशिष्ट वैल्यू के बजाय ऐसे किसी भी डॉक्युमेंट से मेल खाता है जहाँ नाम मौजूद हो—व्यावहारिक रूप से एप्लिकेशन के अभिप्रेत एक्सेस कंट्रोल्स को दरकिनार करते हुए।

असुरक्षित पैटर्न और आम गलतियाँ पहचानना

1. अनुरोध बॉडी पर सहज भरोसा

रिक्वेस्ट बॉडीज़ को सीधे BSON मैप्स में पार्स करना एक ऐसा इंजेक्शन पाथवे बनाता है जहाँ हमलावर दुर्भावनापूर्ण क्वेरी ऑपरेटर्स और जटिल लॉजिकल संरचनाएँ सीधे डेटाबेस ऑपरेशन्स में एम्बेड कर सकते हैं।

// Unsafe
var filter bson.M
_ = json.NewDecoder(req.Body).Decode(&filter)

इसके बजाय, केवल ज्ञात फ़ील्ड्स और टाइप्स पार्स करें:

type QueryInput struct {
    Name string json:"name" validate:"required"
}

2. ढीले टाइप्स स्वीकार करना

इंजेक्शन कमजोरियाँ अक्सर तब उत्पन्न होती हैं जब APIs अत्यधिक उदार डेटा टाइप्स जैसे interface{} या जेनरिक मैप्स स्वीकार करते हैं। ये लचीली संरचनाएँ एम्बेडेड MongoDB ऑपरेटर्स या दुर्भावनापूर्ण ऑब्जेक्ट कॉन्स्ट्रक्ट्स छिपा सकती हैं जो अभिप्रेत क्वेरी लॉजिक को बायपास कर देती हैं।

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

3. क्वेरी स्ट्रिंग्स या क्वेरी ऑपरेटर्स में JSON

URL क्वेरी पैरामीटर्स या सर्च एंडपॉइंट्स के माध्यम से डायनेमिक फ़िल्टरिंग क्षमता उजागर करने वाले APIs आकर्षक अटैक सरफेस बनाते हैं। हमलावर अक्सर इन इंटरफेसेज़ को JSON-एन्कोडेड ऑपरेटर्स और कंडीशनल लॉजिक को सीधे क्वेरी स्ट्रिंग्स में एम्बेड करके निशाना बनाते हैं। यह वैध फ़िल्टर पैरामीटर्स को दुर्भावनापूर्ण डेटाबेस ऑपरेशन्स में बदल देता है:

GET /search?filter={"price":{"$gt":0}}

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

उपाय:

  • क्वेरी पैरामीटर्स को पहले से परिभाषित, सुरक्षित मानों तक सीमित करने के लिए फ़ील्ड और ऑपरेटर अलाउलिस्ट्स लागू करें।
  • डेटाबेस फ़िल्टर्स बनाते समय सभी उपयोगकर्ता-प्रदान मानों को स्पष्ट रूप से $eq ऑपरेटर में रैप करें ताकि वैकल्पिक ऑपरेटर इंजेक्शन रोका जा सके।

4. इंजेक्शन से लॉजिकल क्वेरियाँ विस्तारित करना

ऐप्लिकेशन जो उपयोगकर्ता को $or जैसे लॉजिकल ऑपरेटर्स पर नियंत्रण की अनुमति देते हैं, क्वेरी एक्सपैंशन हमलों के अवसर पैदा करते हैं। हमलावर इन ऑपरेटर्स में अतिरिक्त कंडीशनल अभिव्यक्तियाँ इंजेक्ट कर सकते हैं, जिससे क्वेरी का मूल अर्थ बदल सकता है और संभावित रूप से ऑथेंटिकेशन जाँच या डेटा एक्सेस प्रतिबंधों को बायपास किया जा सकता है। 

filter := bson.M{
  "$or": []bson.M{
    {"role": "user"},
    {"active": true},
  },
}

यदि उपयोगकर्ता इनपुट सीधे $or क्लॉज़ में हेरफेर करता है, तो हमलावर अनधिकृत कंडीशन इंजेक्ट कर सकते हैं:

{ "$or": [ {"role": "user"}, {"active": true}, {"isAdmin": true} ] }

यह संशोधित क्वेरी भूमिका-आधारित एक्सेस नियंत्रणों को बायपास कर सकती है, जिससे एडमिनिस्ट्रेटिव डेटा उजागर होने या अनधिकृत उपयोगकर्ताओं को उच्च विशेषाधिकार मिलने की संभावना बढ़ जाती है। लॉजिकल ऑपरेटर्स के डायनेमिक संशोधन को रोकने के लिए सख्त इनपुट वैलिडेशन लागू करें और क्वेरी संरचना पर सीधे उपयोगकर्ता नियंत्रण से बचें। 

GET /search?filter={"price":{"$gt":0}}

कड़े इनपुट वैलिडेशन के बिना, यह तरीका हमलावरों को क्वेरी संरचनाओं में हेरफेर करने और सुरक्षा नियंत्रणों को बायपास करने में सक्षम बनाता है, जिससे संभावित रूप से अनधिकृत डेटा उजागर हो सकता है। 

उपाय:

  • अनुमत फ़ील्ड्स और ऑपरेटर्स के लिए अलाउलिस्ट्स लागू करें, और इन पूर्व-परिभाषित सीमाओं के बाहर आने वाले किसी भी क्वेरी पैरामीटर को अस्वीकार करें।
  • तुलनात्मक या लॉजिकल ऑपरेटर्स के प्रतिस्थापन को रोकने के लिए सभी उपयोगकर्ता इनपुट को $eq ऑपरेटर्स में रैप करके स्पष्ट इक्वैलिटी मिलान लागू करें।

JavaScript निष्पादन फीचर्स

MongoDB कई सर्वर-साइड JavaScript निष्पादन क्षमताएँ प्रदान करता है जो संभावित सुरक्षा जोखिम लाती हैं, जिनमें शामिल हैं:

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

mongod के लिए:

--noscripting

या कॉन्फ़िग फ़ाइल के माध्यम से:

security:
  javascriptEnabled: false

शार्डेड डिप्लॉयमेंट में mongos पर भी यही कॉन्फ़िगरेशन लागू करें।

MongoDB के नेटिव क्वेरी ऑपरेटर्स व्यापक कार्यक्षमता प्रदान करते हैं, जिससे लगभग सभी उपयोग मामलों में JavaScript निष्पादन की आवश्यकता समाप्त हो जाती है। $where क्लॉज़ से पूरी तरह बचें जब तक कि आप इनपुट वैलिडेशन और निष्पादन संदर्भ पर पूर्ण नियंत्रण न रखते हों।

NoSQL इंजेक्शन कैसे रोकें

1. इनपुट को कड़ाई से वैलिडेट करें

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

type LoginInput struct {
    Username string json:"username" validate:"required,alphanum"
    Password string json:"password" validate:"required,min=8"
}

2. उपयोगकर्ताओं से आने वाली क्वेरी संरचना पर भरोसा न करें

सभी डेटाबेस क्वेरियाँ पूर्वनिर्धारित, एप्लिकेशन-नियंत्रित फ़ील्ड मैपिंग्स और क्वेरी टेम्पलेट्स का उपयोग करके बनाएँ। उपयोगकर्ता इनपुट को क्वेरी आर्किटेक्चर, लॉजिकल ऑपरेटर्स, या कंडीशनल संरचनाओं को प्रभावित करने से रोकें जो अभिप्रेत डेटा एक्सेस पैटर्न को पलट सकते हैं।

filter := bson.M{
    "username": input.Username,
    "password": input.Password,
}

बचें:

// Dangerous: allows injection of operators
_ = json.NewDecoder(req.Body).Decode(&filter)

अधिकांश MongoDB ड्राइवर्स स्ट्रॉन्गली-टाइप्ड क्वेरी बिल्डर्स प्रदान करते हैं जो संरचित क्वेरी निर्माण लागू करते हैं और आकस्मिक इंजेक्शन कमजोरियों को रोकते हैं। इन नेटिव इंटरफेसेज़ का लाभ उठाएँ, न कि रॉ क्वेरी मैप्स या BSON ऑब्जेक्ट्स को ऐप्लिकेशन एंडपॉइंट्स के माध्यम से उजागर करें।

filter := bson.M{
    "username": input.Username,
    "password": input.Password,
}

बचें:

// Dangerous: allows injection of operators
_ = json.NewDecoder(req.Body).Decode(&filter)

3. MongoDB ऑपरेटर्स के इंजेक्शन को ब्लॉक करें

उपयोगकर्ता-नियंत्रित इनपुट को क्वेरी ऑपरेटर या लॉजिकल कॉन्स्ट्रक्ट के रूप में कार्य करने से रोकें। सभी उपयोगकर्ता डेटा को निष्पादन योग्य क्वेरी घटकों के बजाय लिटरल वैल्यू के रूप में ट्रीट करें।

इसके बजाय:

filter := bson.M{
    "status": input.Status,
}

इसका उपयोग करें:

filter := bson.M{
    "status": bson.M{"$eq": input.Status},
}

यह तरीका सख्त इक्वैलिटी मिलान लागू करता है और $ne, $in या $regex जैसे इंजेक्ट किए गए ऑपरेटर्स या अन्य लॉजिकल मॉडिफायर्स के निष्पादन को रोकता है जो अभिप्रेत क्वेरी लॉजिक को बायपास कर सकते हैं।

4. डेटाबेस उपयोगकर्ताओं के लिए न्यूनतम विशेषाधिकार अपनाएँ

एप्लिकेशन डेटाबेस कनेक्शन्स को ऐसे यूज़र अकाउंट्स से कॉन्फ़िगर करें जिनके पास केवल इच्छित ऑपरेशन्स के लिए आवश्यक न्यूनतम परमिशन्स हों। सफल इंजेक्शन हमलों से संभावित नुकसान को रोकने के लिए एप्लिकेशन कॉन्फ़िगरेशन्स में एडमिन-लेवल क्रेडेंशियल्स का उपयोग करने से बचें।

5. मॉनिटर करें और परीक्षण करें

असामान्य क्वेरी पैटर्न का पता लगाने के लिए व्यापक लॉगिंग लागू करें और नियमित सुरक्षा परीक्षण प्रोटोकॉल स्थापित करें। निम्न जैसे गलत ढंग से बने पेलोड का उपयोग करके इंजेक्शन हमलों का प्रयास कर एंडपॉइंट सुरक्षा को वैलिडेट करें:

{ "$ne": null }

सुनिश्चित करें कि एप्लिकेशन इसे अस्वीकार करे।

विचार करने योग्य टेस्ट केसेस:

  • स्ट्रिंग्स की जगह ऑब्जेक्ट्स: { "username": { "$ne": null } }
  • स्कैलर्स की जगह ऐरेज़: { "roles": [ { "$gt": "" } ] }
  • क्वेरी वैल्यू के रूप में ऑपरेटर्स: { "field": { "$regex": ".*" } }

सारांश चेकलिस्ट

  • इनपुट वैलिडेशन: सख्त डेटा टाइप्स लागू करें, फॉर्मैट वैलिडेट करें, और अप्रत्याशित फ़ील्ड्स को अस्वीकार करें।
  • क्वेरी निर्माण: सभी क्वेरियाँ पूर्वनिर्धारित स्कीमाज़ और एप्लिकेशन-नियंत्रित टेम्पलेट्स से बनाएँ
  • ऑपरेटर सुरक्षा: उपयोगकर्ता इनपुट में MongoDB ऑपरेटर्स को $eq से वैल्यू रैप करके या टाइप्ड APIs का उपयोग करके ब्लॉक करें।
  • सर्वर-साइड JavaScript: $where क्लॉज़ समाप्त करें और प्रोडक्शन कॉन्फ़िगरेशन्स में JavaScript निष्पादन अक्षम करें।
  • DB एक्सेस कंट्रोल: एप्लिकेशन कनेक्शन्स को न्यूनतम आवश्यक परमिशन्स के साथ कॉन्फ़िगर करें, प्रशासनिक क्रेडेंशियल्स से बचें।
  • टेस्टिंग और मॉनिटरिंग: नियमित इंजेक्शन टेस्टिंग करें और असामान्य क्वेरी पैटर्न्स के लिए लॉगिंग लागू करें।

अंतिम विचार

अनुशासित सुरक्षित कोडिंग प्रथाओं के जरिए NoSQL इंजेक्शन कमजोरियों को पूरी तरह रोका जा सकता है। कड़े इनपुट वैलिडेशन, संरचित क्वेरी निर्माण, और डिफेंस-इन-डेप्थ सुरक्षा नियंत्रण लागू करके डेवलपर्स एप्लिकेशन की लचीलापन और परफॉर्मेंस बनाए रखते हुए इंजेक्शन अटैक वेक्टर्स को समाप्त कर सकते हैं।

सफलता के लिए आपके एप्लिकेशन के संपूर्ण डेटा फ़्लो—प्रारंभिक रिक्वेस्ट पार्सिंग से अंतिम क्वेरी निष्पादन तक—की समझ जरूरी है। सभी इनपुट स्रोतों के लिए ज़ीरो-ट्रस्ट दृष्टिकोण अपनाएँ, सिस्टम सीमाओं पर वैलिडेशन लागू करें, और अपनी पूरी टेक्नोलॉजी स्टैक में डिफेंसिव प्रोग्रामिंग सिद्धांतों को प्राथमिकता दें।

FAQs

यदि MongoDB स्ट्रिंग्स के बजाय BSON का उपयोग करता है, तो भी NoSQL इंजेक्शन जोखिम क्यों है

BSON ऑब्जेक्ट बनने से पहले भी इंजेक्शन हो सकता है। यदि उपयोगकर्ता इनपुट को बिना वैलिडेशन के map[string]interface{} या interface{} जैसे लचीले टाइप्स में पार्स किया जाता है, तो हमलावर $ne या $or जैसे MongoDB ऑपरेटर्स इंजेक्ट कर सकते हैं और क्वेरी लॉजिक में हेरफेर कर सकते हैं।

क्या किसी रिक्वेस्ट बॉडी को सीधे bson.M या map[string]interface{} में डिकोड करना सुरक्षित है?

नहीं। यह उपयोगकर्ताओं को मनमाने क्वेरी ऑपरेटर्स इंजेक्ट करने देता है। हमेशा अनुरोध डेटा को सख्त टाइप्स (जैसे, Go structs) से मैप करें और क्वेरियाँ बनाने से पहले इनपुट वैलिडेट करें।

यदि इनपुट वैलिडेट है तो $where का उपयोग करने में क्या समस्या है?

भले ही इनपुट आंशिक रूप से वैलिडेट हो, $where सर्वर पर JavaScript चलाता है। एस्केपिंग या वैलिडेशन में कोई भी गलती कोड इंजेक्शन की ओर ले जा सकती है। $where से पूरी तरह बचना या अपने MongoDB कॉन्फ़िग में स्क्रिप्टिंग अक्षम करना अधिक सुरक्षित है।

मैं कैसे जाँचूँ कि मेरा एंडपॉइंट NoSQL इंजेक्शन के प्रति संवेदनशील है?

निम्न जैसे पेलोड इंजेक्ट करके आज़माएँ:

{ "username": { "$ne": null } }

यदि एंडपॉइंट एक वैध प्रतिक्रिया देता है या लॉजिक (जैसे, लॉगिन) को बायपास कर देता है, तो इनपुट सही तरह से वैलिडेट या नियंत्रित नहीं है।

Go में सुरक्षित रूप से क्वेरियाँ बनाने का सबसे अच्छा तरीका क्या है?

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

विषय
MongoDB
NoSQL