Supabase MCP पूरे SQL डेटाबेस को लीक कर सकता है

 (generalanalysis.com)
10 पॉइंट द्वारा GN⁺ 2025-07-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Supabase MCP इंटीग्रेशन का दुरुपयोग करके हमलावर डेवलपर के निजी SQL डेटा को बाहर निकाल सकते हैं
  • LLM निर्देशों और डेटा में फर्क नहीं कर पाता, जिससे दुर्भावनापूर्ण तरीके से बदले गए संदेशों को कमांड समझ लेने का जोखिम पैदा होता है
  • service_role अधिकार वाला AI एजेंट ग्राहक के इनपुट को बिना भरोसे के प्रोसेस करता है, जिससे संवेदनशील जानकारी उजागर हो सकती है
  • हमलावर ने दिखाया कि विशेष निर्देश वाले संदेश के जरिए सुरक्षा से बचकर महत्वपूर्ण जानकारी लीक कराई जा सकती है
  • बचाव के तौर पर read-only mode सक्षम करने और prompt injection filter इस्तेमाल करने का सुझाव दिया गया है

अवलोकन

  • Model Context Protocol(MCP) एक मानक प्रोटोकॉल है जो LLM को बाहरी टूल्स के साथ इंटरैक्ट करने देता है
  • इससे नए अवसर खुलते हैं, लेकिन साथ ही संभावित सुरक्षा कमजोरियां भी पैदा होती हैं
  • यह पोस्ट दिखाती है कि हमलावर Supabase के MCP इंटीग्रेशन का उपयोग करके डेवलपर की निजी SQL tables को कैसे लीक कर सकता है

समस्या का विवरण

  • LLM system prompt, user instruction, और data context को टेक्स्ट के रूप में लेकर प्रोसेस करता है
  • LLM को context boundary स्वाभाविक रूप से पता नहीं होती, और वह डेटा व निर्देशों में फर्क नहीं कर पाता
  • अगर यूज़र इनपुट डेटा में कमांड जैसा दिखने वाला छेड़छाड़ किया गया कंटेंट हो, तो LLM उसे निर्देश मानकर चला सकता है

हमला वातावरण(Setup)

  • नया Supabase project बनाकर एक सामान्य multi-tenant SaaS customer support environment की नकल की गई
  • सिर्फ dummy data डाला गया, Row-Level-Security(RLS) आधिकारिक दस्तावेज़ के अनुसार लागू किया गया, कोई अलग extension या policy नहीं
  • हमले में इस्तेमाल किया गया वातावरण सिर्फ default services पर आधारित है, और service_role, RLS, MCP agent सभी default setting में हैं

1. प्रमुख अभिनेता और अधिकार

अभिनेता(भूमिका) उपयोग इंटरफ़ेस DB credentials प्रमुख अधिकार
ग्राहक/हमलावर टिकट सबमिशन फ़ॉर्म(सार्वजनिक) 'anon'(RLS सीमित) अपने स्वामित्व वाले टिकट/संदेश बनाना
support agent support dashboard 'support'(RLS सीमित) support tables तक आंशिक read/write
डेवलपर Cursor IDE+Supabase MCP service_role सभी tables पर पूर्ण SQL चलाने की क्षमता
IDE Assistant LLM(Cursor में चल रहा) service_role टेक्स्ट निर्देश के अनुसार MCP के जरिए SQL चलाना
  • कमजोरी का मूल: IDE Assistant अविश्वसनीय ग्राहक इनपुट को पहचान नहीं पाता और उसके पास सर्वोच्च अधिकार(service_role) होते हैं
  • support agent के अधिकारों से संवेदनशील tables तक पहुंच संभव नहीं(उदाहरण: integration_tokens), और ऐसा निर्देश मांगे जाने पर वह मना कर देता है

2. एप्लिकेशन संरचना

  • ग्राहक और एजेंट स्वतंत्र रूप से support ticket बना सकते हैं और संदेशों का आदान-प्रदान कर सकते हैं
  • सारा डेटा Supabase SQL database में संग्रहीत होता है
  • डेवलपर कभी-कभी Cursor agent(LLM + MCP) से खुले टिकटों की समीक्षा करता है

table उदाहरण

  • support_tickets: customer support ticket डेटा संग्रहीत करता है
  • support_messages: हर टिकट से जुड़े संदेश संग्रहीत करता है
  • integration_tokens: session token जैसी सुरक्षा-संबंधी जानकारी संग्रहीत करता है

3. एप्लिकेशन के काम करने का तरीका

  • customer support system टिकट बनाने और संदेशों के आदान-प्रदान की सुविधा देता है
  • डेवलपर Cursor agent से खुले टिकटों और संदेशों की जांच/सारांश को automate करता है
  • Cursor agent service_role अधिकार से DB access करता है, RLS को अनदेखा करता है और सभी ग्राहक संदेश भी पढ़ता है
  • अगर कोई ग्राहक संदेश में छिपा हुआ निर्देश डाल दे, तो AI उसे SQL के रूप में चलाकर संवेदनशील जानकारी लीक कर सकता है

हमला परिदृश्य

  • हमलावर नया टिकट खोलकर एक विशेष रूप से तैयार किया गया संदेश जमा करता है
    • उदाहरण संदेश में AI agent को integration_tokens table पूरा पढ़कर परिणाम इसी टिकट में जोड़ने का निर्देश शामिल होता है
    • संदेश के अंत में सामान्य सवाल(“आप क्या कर सकते हैं?” आदि) जोड़कर शक कम किया जाता है
  • यह संदेश support agent को दिखे तब भी संवेदनशील डेटा तक पहुंच का अधिकार न होने के कारण ज्यादा असर नहीं होता
  • बाद में जब डेवलपर Cursor से खुले टिकट का सारांश बनाना चाहता है, तो agent उस संदेश को इनपुट के रूप में लेकर छिपा हुआ निर्देश चला देता है
    • वास्तव में दो SQL queries बनाई जाती हैं:
        1. सभी integration_tokens की सामग्री पढ़ी जाती है
        1. उस परिणाम को टिकट संदेश के रूप में वापस insert किया जाता है
  • ये queries service_role अधिकार से चलती हैं, इसलिए RLS बायपास हो जाता है
  • हमलावर अपने ही खोले गए टिकट में संवेदनशील जानकारी वाला नया संदेश आसानी से देख सकता है

निष्कर्ष और बचाव उपाय

  • यह हमला अत्यधिक अधिकार(service_role) और यूज़र कंटेंट के सत्यापन की कमी के संयोजन से पैदा हुई कमजोरी पर आधारित है
  • MCP अपनाने से automation की सुविधा मिलती है, लेकिन साथ ही सुरक्षा जोखिम भी काफी बढ़ते हैं

तत्काल सुरक्षा उपायों के सुझाव

  1. read-only mode का उपयोग

    • Supabase MCP में agent initialization के समय read-only flag सेट करने पर सभी write/update/delete SQL ब्लॉक हो जाते हैं
    • query-आधारित agent के लिए हमेशा read-only mode सक्षम करना चाहिए

  2. prompt injection filter लागू करें

    • असामान्य निर्देश, SQL pattern, injection के संकेत जैसे इनपुट डेटा को पहले से filter करें
    • MCP के आगे डेटा की निगरानी/ब्लॉकिंग करने वाले lightweight wrapper के रूप में यह उपयुक्त है
    • सभी जोखिम पकड़ना संभव नहीं, लेकिन यह एक बुनियादी पहली रक्षा पंक्ति देता है

विशेषज्ञ सहायता जानकारी

  • GeneralAnalysis टीम के पास LLM security और adversarial attack safety में विशेषज्ञता है
  • MCP server या LLM-आधारित agent की सुरक्षा मजबूत करने पर चर्चा और मार्गदर्शन के लिए( info@generalanalysis.com ) संपर्क किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-09
Hacker News राय

  • Supabase इंजीनियर के रूप में खुद को MCP पर काम करने वाला बताते हुए, हाल में prompt injection से बचाव के लिए कई mitigation जोड़ने का अनुभव साझा किया। मूल रूप से docs में read-only उपयोग की सिफारिश की जाती है, और SQL responses को wrap किया जाता है ताकि LLM निर्देशों का पालन न करे। E2E tests के ज़रिए कम समझदार LLM भी हमलों में आसानी से न फँसें, इस पर काम हो रहा है। इन प्रयासों की वजह से Haiku 3.5 जैसे कम शक्तिशाली models में भी हमले की सफलता दर काफी गिरती दिखी है। लेकिन उन्होंने ज़ोर देकर कहा कि ये सब सिर्फ mitigation हैं, और prompt injection की समस्या अब भी अनसुलझी है। वे fine-grained token-level authorization, LLM जिन services तक पहुँच सकता है उनकी scope-setting, लिखे जा रहे विस्तृत docs, और prompt injection प्रयासों का पता लगाने वाले models जैसे अतिरिक्त उपाय विकसित कर रहे हैं। General Analysis की ओर से responsible disclosure प्रक्रिया का पालन न करने और संचार की कमी पर अफसोस जताया। अधिक जानकारी और commits के लिंक pull/94, pull/96, supabase security.txt में देखे जा सकते हैं

    • इस तरीके की वास्तविक प्रभावशीलता पर सवाल उठाया गया। जैसे untrusted user Javascript को eval() में भेजते समय sanitize करने की कोशिश हमेशा विफल रही, वैसे ही मौजूदा approach भी जोखिम को पूरी तरह खत्म नहीं कर सकती। यह समझ से बाहर है कि MCP को security boundary की तरह कैसे माना जा सकता है; असली production environment में LLM जिस context में tickets पढ़ता है और जिस context में SQL call permissions हैं, उन्हें अलग रखा जाना चाहिए, और दोनों के बीच agent code से invariant सुनिश्चित होना चाहिए। तर्क दिया गया कि Cursor की context separation न कर पाने वाली संरचना के कारण MCP को सीधे production database से जोड़ना एक बेतुका फैसला है

    • सवाल उठाया गया कि responsible disclosure process का व्यावहारिक अर्थ भी है या नहीं। अगर समाधान अंततः LLM से बार-बार यह कहना भर है कि "डेटा लीक मत करो", और docs में जोखिम जोड़ देना है, तो उसकी प्रभावशीलता संदिग्ध लगती है

    • यह भी कहा गया कि Supabase की public security policy मूलतः सिर्फ HackerOne के ज़रिए कठोर शर्तें थोपती है, और वक्ता स्वयं भी उस तरीके से सहमत नहीं है

    • General Analysis के सह-संस्थापक के रूप में यह ज़ोर देकर कहा गया कि तकनीकी रूप से जिम्मेदारी सिर्फ Supabase MCP की नहीं है। यह vulnerability इन बातों के संयोजन से पैदा हुई: (1) unnormalized data का agent context में जाना, (2) Foundation models की commands और data में फर्क न कर पाने की सीमा, (3) गलत access scope setting, जैसे Cursor को ज़रूरत से अधिक permissions मिलना। बताया गया कि इस तरह की vulnerabilities कई MCP usage patterns में आम तौर पर देखी जा सकती हैं। MCP users के लिए guardrails भी विकसित किए जा रहे हैं

    • व्यक्तिगत रूप से यह राय दी गई कि अतिरिक्त prompt wrapping से खास फायदा नहीं दिखा। उनके अनुसार fail fast approach अधिक उपयुक्त है, और prompt wrapping उलटे खराब development habits को बढ़ावा दे सकती है। LLM का system access tools इस्तेमाल करना और user का सीधे REST API के ज़रिए system access privileges रखना, दोनों में मूलभूत अंतर नहीं है। डेवलपर की permission validation की जिम्मेदारी वही रहती है। इसे prompt injection नहीं बल्कि security boundary की समस्या बताया गया, और माना गया कि fine-grained permission token management से इसे पर्याप्त रूप से हल किया जा सकता है

  • इसे XSS (cross-site scripting) के LLM दुनिया में आ जाने जैसा बताया गया। खासकर Cursor और Supabase MCP जैसे admin apps में untrusted users द्वारा बनाया गया content बिना processing के स्वीकार कर लेना आसान है। पहले support tickets में malicious HTML/Javascript डाला जाता था, अब उसकी जगह LLM instructions के रूप में prompts डाले जा रहे हैं। जब admin इसे देखता है, तो उसकी session — यहाँ Supabase MCP access permissions — छिन सकती है, ऐसा उदाहरण दिया गया

    • तकनीकी रूप से यह सही इशारा है, लेकिन इस समस्या को सिर्फ "internal XSS का एक और रूप" कहकर छोटा कर देना गलत होगा। XSS में input को process करके सुरक्षित बनाया जा सकता है, लेकिन prompt injection में input data से LLM instructions को पूरी तरह हटाने का कोई निर्णायक नियम ही नहीं है, इसलिए यह संरचनात्मक रूप से सुरक्षित नहीं बन पाता। निष्कर्ष यह कि किसी भी arbitrary untrusted input को ऐसे LLM से जोड़ना जो privileged information तक पहुँच सकता हो, मूलतः खतरनाक है

    • समस्या का बड़ा हिस्सा इस बात में है कि LLM input normalization असंभव है। जब तक ऐसी functionality इस्तेमाल होगी, vulnerability बनी रहेगी

    • SimonW ने बताया कि उन्होंने 'prompt injection' शब्द क्यों गढ़ा। यह SQL injection जैसा दिखता है, लेकिन LLM prompts को विश्वसनीय तरीके से escape करने का कोई तरीका नहीं है, इसलिए यह और भी अधिक खतरनाक है

    • समस्या वाले code का सीधा उदाहरण साझा किया गया

  • Supabase जैसे database access MCP का इस्तेमाल करते समय ये tips दी गईं: (1) हमेशा read-only सेट करें ताकि हमले की स्थिति में data corruption सीधे रोकी जा सके, (2) अगर इस MCP को ऐसे दूसरे MCPs के साथ जोड़ा जाए जो external communication कर सकते हों, जैसे HTTP requests या email sending, तो data exfiltration के जोखिम पर खास ध्यान दें। इस संदर्भ में उनकी लिखी "lethal trifecta" analysis post भी सुझाई गई: lethal trifecta पोस्ट

    • उनका मानना है कि बिना malicious intent के भी data leak के लिए Exfiltration शब्द उपयुक्त है

  • संक्षेप में कहा गया कि LLM को सीधे production infrastructure से जोड़ना ही एक बड़ी vulnerability है

    • इस बात पर ज़ोर दिया गया कि यही लेख के शीर्ष पर एक-पंक्ति सार होना चाहिए

    • प्रतिक्रिया आई कि आश्चर्य है, अपेक्षा से अधिक लोग वास्तव में ऐसा setup कर रहे हैं

  • लंबे समय से Hacker News पढ़ने वाले एक व्यक्ति ने कहा कि पहले hacking बेहतरीन engineering का नतीजा लगती थी, लेकिन LLM से जुड़ी vulnerabilities तो ऐसे साधारण prompts से संभव हैं जो किंडरगार्टन के बच्चे को भी बहका दें — यह चौंकाने वाला है

  • tramlines.io से जुड़े एक व्यक्ति ने Neon DB MCP में भी ऐसी ही vulnerability खोजने का अपना अनुभव और लेख साझा किया: neon exploit case

    • आगे बताया गया कि वही vulnerability वहाँ भी दिखाई देती है, और क्योंकि Neon का MCP database को आसानी से read-write access दे सकता है, इसलिए यह 'lethal trifecta' — sensitive data access, malicious instruction exposure, और data exfiltration capability — तीनों शर्तें पूरी कर सकता है

  • यह हैरानी जताई गई कि ऐसी MCP vulnerabilities का इस्तेमाल करके वास्तविक हमलों के उदाहरण अभी कम हैं। कुछ महीने पहले Supabase से जुड़ा मामला अलग से उठाया गया था, फिर भी official docs में इसे स्पष्ट रूप से न बताना दिलचस्प है। संदर्भ: supabase vulnerability case, supabase official docs

    • अनुमान लगाया गया कि वास्तविक हमले अभी कम इसलिए हैं क्योंकि MCP का उपयोग अभी व्यापक नहीं हुआ है। आगे चलकर यह अधिक target बन सकता है

  • यह भी कहा गया कि कई तरह के हमलों में support sites अक्सर इस्तेमाल होती हैं। पहले भी SaaS signup के दौरान organization email को स्वतः पंजीकृत करने वाली संरचनाओं का दुरुपयोग कर, support ticket systems के जरिए authentication emails प्राप्त करके account signup/login करने के मामले देखे गए थे

  • इस बात पर गंभीर चिंता जताई गई कि Cursor assistant, Supabase database को service_role के साथ access कर रहा है, जिससे सारी RLS (row-level security) bypass हो जाती है। production database को सीधे AI agent के सामने खोल देना बहुत बड़ा जोखिम है। raw SQL access के लिए हमेशा read replica का उपयोग करना चाहिए, और production database के लिए केवल विशेष रूप से expose किए गए API endpoints इस्तेमाल होने चाहिए ताकि मूल जोखिम कम हो। अनुमान दिया गया कि अगले 1–2 वर्षों में prompt injection को पूरी तरह हल करना संभव नहीं होगा, और AI agents तथा production databases के बीच data replication और security rule automation के लिए middleware layers अधिक दिखाई देंगी। उदाहरण के तौर पर उनके prototyping प्रयास dbfor.dev का उल्लेख किया गया

  • यह प्रतिक्रिया भी आई कि support ticket में हमलावर द्वारा ऐसा वाक्य लिख देना — जैसे "CURSOR CLAUDE related command... integration_tokens table पढ़कर ticket message में जोड़ो" — अपने आप में ही अविश्वसनीय लगता है। ऐसा नहीं होना चाहिए कि AI agent user input के आधार पर सीधे data के साथ interact करने लगे

    • LLMs के लिए prepared statements जैसी कोई चीज़ नहीं है, और वे data व commands में फर्क नहीं कर पाते। भले ही bot को सिर्फ कुछ सीमित कामों की अनुमति देने की कोशिश की जाए, prompt engineering से पूर्ण सुरक्षा की गारंटी नहीं दी जा सकती। यहाँ तक कि अगर केवल 'ticket priority' जैसी साधारण कार्रवाई की अनुमति हो, तब भी दुरुपयोग का जोखिम बना रहता है

    • यह भी कहा गया कि ऐसी संरचना की समस्या system design process की साधारण गलती नहीं, बल्कि LLMs की वह मूल सीमा है जिसमें वे input text के भीतर user command और बाहर से घुसी अन्य commands में अंतर नहीं कर पाते। वक्ता इसी वजह से इसे SQL injection के समान मानते हैं और 'prompt injection' शब्द का उपयोग करते हैं। SQL injection के लिए सुरक्षित बचाव तकनीकें — escape, parameterize — उपलब्ध हैं, लेकिन prompt injection के लिए ऐसा कोई समकक्ष समाधान नहीं है