अपने MCP सिस्टम को सुरक्षित करें: 11 आम जोखिम और उनसे बचाव के तरीके

MCP जोखिम मोटे तौर पर तीन श्रेणियों में आते हैं: LLM हेरफेर, डेटा और एक्सेस सुरक्षा, और इन्फ्रास्ट्रक्चर से जुड़ी कमज़ोरियाँ।

चूँकि MCP सर्वर अक्सर कई तरह के आंतरिक सिस्टम तक पहुँच देते हैं, इसलिए संभावित सुरक्षा जोखिम अधिक होता है। हालाँकि, इसकी संभावना काफ़ी हद तक सेटअप पर निर्भर करती है।

व्यक्ति और एंटरप्राइज़ अपने सिस्टम को सुरक्षित रखने के लिए कई कदम उठा सकते हैं, और प्रोटोकॉल हमेशा उन क्षमताओं और डेटा के अनुपात में होने चाहिए जिन्हें कनेक्ट किए गए MCP सर्वर उजागर कर सकते हैं।

MCP और MCP सुरक्षा क्या है?

Model Context Protocol (MCP), Anthropic द्वारा बनाया गया एक ओपन स्टैंडर्ड है, जो LLM-आधारित ऐप्स (या होस्ट) को बाहरी सिस्टम से जोड़ता है।

MCP सिस्टम में तीन मुख्य घटक होते हैं: होस्ट, क्लाइंट और सर्वर। होस्ट, जो अक्सर एक AI असिस्टेंट होता है, एक क्लाइंट के ज़रिए किसी बाहरी MCP सर्वर से कनेक्ट होता है। इसके बाद यह बाहरी फ़ंक्शनैलिटी (टूल) चलाने, डेटा (संसाधन) प्राप्त करने, या LLM की कॉन्टेक्स्ट विंडो में जोड़ने के लिए प्रॉम्प्ट पाने के अनुरोध भेज सकता है।

बड़ा करें

MCP सुरक्षा का अर्थ उन प्रोटोकॉल से है जो किसी MCP सिस्टम के कनेक्शन और घटकों की सुरक्षा करते हैं। कई प्रमुख चुनौतियाँ केवल MCP से जुड़ी हैं, जिनमें यह तथ्य भी शामिल है कि AI ऐप्स में अक्सर एजेंटिक क्षमताएँ होती हैं और संदेशों में दुर्भावनापूर्ण निर्देश छिपाए जा सकते हैं।

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

MCP खतरे कितने गंभीर हैं?

MCP तेज़ी से एक लोकप्रिय LLM तकनीक बन गया है, और कई संगठन और उपभोक्ताओं के लिए बने ऐप्स इसका उपयोग करते हैं। चूँकि MCP सर्वर कोड में लिखे गए प्रोग्राम होते हैं, इसलिए किसी भी अन्य ऐप्लिकेशन की तरह उनमें भी कमज़ोरियाँ होती हैं।

हालाँकि, जब संगठन नियंत्रित डिप्लॉयमेंट में MCP का उपयोग करते हैं, तो यह आम तौर पर सुरक्षित होता है। भरोसेमंद सर्वर और सत्यापित अनुमतियों वाला सिस्टम बनाने और किसी स्वायत्त एजेंट को एक दर्जन बिना जाँचे सर्वर से जोड़ देने में बहुत बड़ा अंतर है।

खतरा #1: अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन

कोई हमलावर LLM को निशाना बनाने वाले निर्देश किसी दस्तावेज़, वेबपेज या ऐसे टूल आउटपुट के अंदर रख सकता है जिसे MCP सर्वर लौटाता है। अगर होस्ट इस सामग्री को कॉन्टेक्स्ट विंडो में जोड़ देता है, तो इस बात की संभावना रहती है कि LLM इसे असली निर्देश समझ ले।

इतना ही नहीं, ये निर्देश ऊपर से देखने पर उचित लग सकते हैं। उदाहरण के लिए, प्राप्त किया गया कोई सपोर्ट टिकट LLM से कह सकता है कि जवाब तैयार करने से पहले वह ग्राहकों के संवेदनशील रिकॉर्ड एक्सपोर्ट करे।

अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन से कैसे बचें

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

खतरा #2: टूल पॉइज़निंग और रग पुल

टूल पॉइज़निंग हमले में, किसी MCP टूल के विवरण या स्कीमा में दुर्भावनापूर्ण कोड जोड़ दिया जाता है। इससे डिस्कवरी चरण में LLM प्रभावित हो सकता है, जब MCP पहली बार उपलब्ध टूल उजागर करता है।

बड़ा करें

रग पुल एक खास तरह का टूल पॉइज़निंग है, जिसमें स्वीकृत मेटाडेटा बदल दिया जाता है। टूल पॉइज़निंग का यह रूप किसी दुर्भावनापूर्ण टूल को सीधे चलाने के बजाय, मॉडल के भरोसेमंद टूल इस्तेमाल करने के तरीके को बदल सकता है।

टूल पॉइज़निंग और रग पुल से कैसे बचें

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

खतरा #3: ज़रूरत से ज़्यादा अनुमतियाँ

उपयोगकर्ताओं का MCP सर्वर और (होस्ट के ज़रिए) कनेक्ट किए गए LLM को किसी काम के लिए ज़रूरत से ज़्यादा अनुमतियाँ देना आम बात है। उदाहरण के लिए, जहाँ केवल पढ़ने की अनुमति काफ़ी हो, वहाँ लिखने की अनुमति देना, या फ़ाइलों के किसी आंतरिक सिस्टम (जैसे Google Drive) तक पूरी पहुँच देना।

अनुमतियों का यह व्यापक विस्तार दुर्भावनापूर्ण टूल कॉल जैसी अन्य कमज़ोरियों के असर का दायरा बढ़ा सकता है। किसी एंटरप्राइज़ में जब उपयोगकर्ता AI टूल के साथ रोज़मर्रा के काम के दौरान विशेषाधिकार देते जाते हैं, तो अनुमतियों का “जुड़ते जाना” आम है (विशेषाधिकार संचय)।

ज़रूरत से ज़्यादा अनुमतियों से कैसे बचें

इस समस्या से बचने का सबसे सीधा तरीका अनुमतियों और OAuth स्कोप (पढ़ना, लिखना, पूरी पहुँच आदि) को सीमित करना है। उपयोगकर्ता की मंज़ूरी, ख़ासकर संवेदनशील कार्रवाइयों के लिए, इसका एक अहम हिस्सा है, लेकिन अनुमतियों को सिस्टम स्तर (ऑपरेटिंग सिस्टम, MCP होस्ट और सर्वर) पर भी नियंत्रित किया जाना चाहिए।

खतरा #4: कमज़ोर प्रमाणीकरण और प्राधिकरण

प्रमाणीकरण किसी MCP सर्वर से कनेक्ट होने वाले उपयोगकर्ताओं या ऐप्लिकेशन की पहचान सत्यापित करता है। प्राधिकरण तय करता है कि वे किन टूल और संसाधनों तक पहुँच सकते हैं।

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

कमज़ोर प्रमाणीकरण और प्राधिकरण से कैसे बचें

रिमोट MCP सर्वर के लिए OAuth-आधारित प्रमाणीकरण, कम अवधि वाले टोकन और रोल-आधारित एक्सेस कंट्रोल (RBAS), ये सभी ऐसे उपाय हैं जो कमज़ोर प्राधिकरण के जोखिम को कम करने में मदद करते हैं। रोल-आधारित एक्सेस इसलिए उपयोगी है क्योंकि यह उपयोगकर्ताओं को उनकी अनुमतियों से बाहर के डेटा और टूल तक पहुँचने से रोकता है, भले ही सर्वर के पास खुद उनकी पहुँच हो।

खतरा #5: क्रेडेंशियल लीक और दुरुपयोग

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

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

क्रेडेंशियल लीक और दुरुपयोग से कैसे बचें

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

खतरा #6: कन्फ़्यूज़्ड डेप्युटी हमले

कन्फ़्यूज़्ड-डेप्युटी हमला तब होता है जब कोई हमलावर किसी भरोसेमंद ऐप्लिकेशन को धोखा देकर उसकी अनुमतियों का उपयोग ऐसी कार्रवाई के लिए करवाता है जिसे किसी वैध उपयोगकर्ता ने अधिकृत नहीं किया है। इस मामले में, MCP सर्वर ही डेप्युटी होता है।

बड़ा करें

हमलावर किसी दुर्भावनापूर्ण प्रक्रिया, जैसे टूल कॉल या डेटा प्राप्ति, को अंजाम देने के लिए MCP सर्वर की किसी कमज़ोरी (जैसे कमज़ोर OAuth सत्यापन) का फ़ायदा उठाएगा।

कन्फ़्यूज़्ड डेप्युटी हमलों से कैसे बचें

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

खतरा #7: दुर्भावनापूर्ण सर्वर और असुरक्षित हो चुकी डिपेंडेंसी

MCP सर्वर में दुर्भावनापूर्ण कोड हो सकता है (वे मूल रूप से बाहरी प्रोग्राम ही होते हैं) या वे थर्ड-पार्टी लाइब्रेरी जैसी असुरक्षित हो चुकी डिपेंडेंसी पर निर्भर हो सकते हैं। यह केवल MCP की समस्या नहीं, बल्कि सॉफ़्टवेयर सप्लाई चेन की समस्या है।

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

दुर्भावनापूर्ण सर्वर और असुरक्षित हो चुकी डिपेंडेंसी से कैसे बचें

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

खतरा #8: सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF)

सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF) तब होती है जब कोई हमलावर किसी MCP सर्वर को धोखा देकर उससे ऐसे आंतरिक पतों पर नेटवर्क अनुरोध भिजवाता है जिन तक पहुँचने का उपयोगकर्ता का कोई इरादा नहीं था।

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

सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF) से कैसे बचें

MCP सर्वर को हमेशा URL सत्यापित करने चाहिए, प्रतिबंधित आंतरिक नेटवर्क पतों तक पहुँच ब्लॉक करनी चाहिए और आउटबाउंड नेटवर्क एक्सेस को रोकना चाहिए। रीडायरेक्ट पर भी यही प्रोटोकॉल लागू होना चाहिए।

खतरा #9: सत्र हाइजैकिंग

सत्र हाइजैकिंग में एक हमलावर MCP क्लाइंट और सर्वर के बीच के किसी सक्रिय कनेक्शन पर नियंत्रण कर लेता है।

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

कैसे बचाव करें

किसी MCP सिस्टम के सभी ऐप्लिकेशन में सख्त पहचान सत्यापन से सत्र हाइजैकिंग का जोखिम कम किया जा सकता है। सत्र पहचानकर्ताओं को पहचाने जाने से रोकने के लिए MCP क्लाइंट और रिमोट सर्वर के बीच एन्क्रिप्शन भी ज़रूरी है।

खतरा #10: मिक्स-अप हमले

मिक्स-अप हमले में, हमलावर किसी MCP क्लाइंट को धोखा देकर उससे एक प्राधिकरण कोड ऐसे दुर्भावनापूर्ण प्राधिकरण सर्वर को भिजवाता है जो क्लाइंट और MCP सर्वर के बीच मौजूद होता है। प्राधिकरण सर्वर एक ऐसा ऐप्लिकेशन है जो यह जाँचने के बाद OAuth एक्सेस टोकन जारी करता है कि अनुरोधित एक्सेस अधिकृत है।

बड़ा करें

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

मिक्स-अप हमलों से कैसे बचें

MCP क्लाइंट को पूरी OAuth प्रक्रिया के दौरान प्राधिकरण सर्वर की पहचान सत्यापित करनी चाहिए। ख़ास तौर पर, उन्हें सर्वर के जारीकर्ता पहचानकर्ता (iss) की तुलना अपेक्षित पहचान से करनी चाहिए और मेल न खाने पर उसे अस्वीकार करना चाहिए।

खतरा #11: लोकल MCP सर्वर में सेंधमारी

कई MCP सर्वर उपयोगकर्ता की लोकल मशीन पर चलते हैं। उपयोगकर्ता सर्वर को किसी थर्ड पार्टी से इंस्टॉल कर सकते हैं या उसे खुद बना सकते हैं। अगर कोई हमलावर इस लोकल MCP सर्वर में सेंध लगा सकता है, तो वह संभावित रूप से लोकल सिस्टम के बड़े हिस्सों तक पहुँच हासिल कर सकता है।

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

लोकल MCP सर्वर में सेंधमारी से कैसे बचें

लोकल MCP सर्वर का उपयोग करते समय सैंडबॉक्सिंग और सख्त सहमति प्रोटोकॉल अहम हैं। MCP सर्वर केवल भरोसेमंद प्रदाताओं से ही इंस्टॉल किए जाने चाहिए, और ऑपरेटिंग सिस्टम की अनुमतियों को यह सीमित करना चाहिए कि वे किन डायरेक्टरी तक पहुँच सकते हैं।

MCP कमज़ोरियाँ अक्सर नए रूप में पुराने खतरे ही होती हैं

MCP कमज़ोरियाँ अक्सर स्थापित जोखिमों और हमले के तरीकों के नए इस्तेमाल से पैदा होती हैं। MCP, LLM, MCP सर्वर और बाहरी सेवाओं के बीच होने वाले इंटरैक्शन के ज़रिए हमलावरों के लिए इन कमज़ोरियों का फ़ायदा उठाने के नए रास्ते खोलता है।

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