पिछले दरवाजे के रूप में ब्राउज़र: क्लाइंट-साइड एलएलएम सीक्रेट एक्सट्रैक्शन डिमिस्टिफाईड

पिछले दरवाजे के रूप में ब्राउज़र: क्लाइंट-साइड एलएलएम सीक्रेट एक्सट्रैक्शन डिमिस्टिफाईड

बहुत लंबे समय से, हमने "एआई सुरक्षा चेतावनियों" को दूर के खतरों या अकादमिक जिज्ञासाओं के रूप में माना है। हमने त्वरित इंजेक्शन, जेलब्रेक और दबी आवाज़ में डेटा लीक के बारे में सुना है, जिसके बाद अक्सर कंधे उचकाते हैं और कहते हैं "हम उस तक पहुंच जाएंगे।" हालाँकि, हाल के इंटरैक्टिव प्रदर्शनों ने उस आरामदायक भ्रम को तोड़ दिया है। यह अब कोई सैद्धांतिक भेद्यता नहीं है; यह बड़े भाषा मॉडल (एलएलएम) से संवेदनशील जानकारी निकालने के लिए एक लाइव, ब्राउज़र-आधारित, क्लाइंट-साइड शोषण है [2]। यदि आप एलएलएम-संचालित एप्लिकेशन तैनात कर रहे हैं, विशेष रूप से वेब-फेसिंग कुछ भी, तो आपकी "भविष्य की समस्या" बस एक बहुत ही वर्तमान, बहुत सार्वजनिक और संभावित रूप से बहुत शर्मनाक दायित्व बन गई है।

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

मॉडल सुरक्षा का भ्रम

कई उद्यमों ने "सुरक्षित" एलएलएम में भारी निवेश किया है, या तो मालिकाना मॉडल को ठीक कर रहे हैं या कथित रेलिंग के साथ एंटरप्राइज़-ग्रेड एपीआई पर निर्भर हैं। अंतर्निहित धारणा यह है कि यदि मॉडल स्वयं मजबूत है, तो उसके शीर्ष पर निर्मित एप्लिकेशन को वह सुरक्षा विरासत में मिलेगी। हाल के प्रदर्शनों से यह एक खतरनाक ग़लतफ़हमी के रूप में सामने आया है। भेद्यता मॉडल की मूल बुद्धिमत्ता या उसके प्रशिक्षण डेटा में नहीं है; यह उस इंटरफ़ेस में है जिसे हम इसके चारों ओर बनाते हैं [1]। यह क्लासिक "मजबूत तिजोरी, कमज़ोर सामने वाला दरवाज़ा" समस्या है। आपके पास दुनिया में सबसे उन्नत, कठोर एलएलएम हो सकता है, लेकिन यदि आपके एप्लिकेशन का इनपुट पार्सर अनुभवहीन है, या आपका आउटपुट फ़िल्टर अस्तित्वहीन है, तो आप अनिवार्य रूप से महत्वपूर्ण जानकारी को किसी के भी खोजने के लिए खुला छोड़ रहे हैं।

यह "शीघ्र इंजेक्शन" तकनीक विशेष रूप से चिंताजनक है क्योंकि यह एलएलएम की अंतर्निहित प्रकृति का लाभ उठाती है: निर्देशों और पूर्ण पैटर्न का पालन करने की इसकी क्षमता। उपयोगकर्ता के इनपुट में सावधानीपूर्वक निर्मित उपसर्ग को इंजेक्ट करके, हमलावर मॉडल की आंतरिक स्थिति में हेरफेर कर सकता है, जिससे उसे ऐसी जानकारी प्रकट करने के लिए मजबूर किया जा सकता है जिसका इरादा कभी नहीं था [3]। यहां "एक-बिट" या पुनरावृत्तीय पहलू महत्वपूर्ण है। इसका तात्पर्य एक व्यवस्थित, नियंत्रित घुसपैठ से है, न कि केवल एक अराजक डेटा डंप से। कल्पना कीजिए कि एक हमलावर बार-बार पूछ रहा है, "क्या रहस्य का पहला अक्षर 'ए' है?" फिर "क्या यह 'बी' है?" और इसी तरह। हाँ, यह धीमा है, लेकिन यह अविश्वसनीय रूप से प्रभावी भी है और यदि आप विशेष रूप से इसकी तलाश नहीं कर रहे हैं तो इसका पता लगाना कठिन है।

आपका ब्राउज़र, उनका हथियार

तथ्य यह है कि यह एक ब्राउज़र-आधारित शोषण है जो गेम को पूरी तरह से बदल देता है। इसका मतलब है:

• प्रवेश में कम बाधा: बुनियादी वेब विकास कौशल और ब्राउज़र वाला कोई भी व्यक्ति इसका प्रयास कर सकता है। किसी विशेष उपकरण या गहन एआई ज्ञान की आवश्यकता नहीं है।
• क्लाइंट-साइड निष्पादन: हमला उपयोगकर्ता की मशीन से उत्पन्न होता है, जिससे नेटवर्क किनारे पर वैध उपयोगकर्ता इनपुट से अंतर करना कठिन हो जाता है।
• तत्काल खतरा: यदि आपका एलएलएम एप्लिकेशन वेब इंटरफ़ेस के माध्यम से लाइव और पहुंच योग्य है, तो यह इस वेक्टर के लिए पहले से ही असुरक्षित है। यह कोई भविष्य का पैच नहीं है; यह वर्तमान आपातकाल है.

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

जिम्मेदारी आपकी है

OpenAI या Google जैसे मॉडल प्रदाताओं के लिए अपने अगले मॉडल अपडेट में इसे ठीक करना कोई समस्या नहीं है। यह एक एप्लिकेशन सुरक्षा समस्या है, और इसे कम करने की जिम्मेदारी पूरी तरह से इन प्रणालियों को तैनात करने वाले डेवलपर्स, सुरक्षा टीमों और सीटीओ के कंधों पर आती है। आपका एलएलएम एक शक्तिशाली, लेकिन अंततः अनुभवहीन इंजन है। यह वही करेगा जो इसे बताया गया है, भले ही वे निर्देश स्पष्ट रूप से अहानिकर उपयोगकर्ता इनपुट के भीतर छिपे हों।

तो अब तुम क्या करते हो*?

तत्काल प्रतिउपाय:

1. आक्रामक इनपुट सैनिटाइजेशन: यह SQL इंजेक्शन या XSS को रोकने से कहीं आगे जाता है। आपको अपने एलएलएम में प्रवेश करने वाले प्रत्येक चरित्र की जांच करने की आवश्यकता है। शीघ्र इंजेक्शन, असामान्य चरित्र अनुक्रम, या अपेक्षित वार्तालाप प्रवाह से बाहर निकलने का प्रयास करने वाले पैटर्न की तलाश करें [4]। यह "बुरे शब्दों" को रोकने के बारे में नहीं है; यह प्रतिकूल संकेतों की पहचान करने के बारे में है। बुनियादी रेगेक्स और अनुमानी विश्लेषण से परे, दुर्भावनापूर्ण इरादे का पता लगाने के लिए सिमेंटिक विश्लेषण लागू करें। असंगत इनपुट पैटर्न की पहचान करने के लिए टोकननाइजेशन और एम्बेडिंग विश्लेषण का उपयोग करें। त्वरित इंजेक्शन प्रयासों का पता लगाने के लिए विशेष रूप से प्रशिक्षित एक माध्यमिक, छोटे एलएलएम या नियम-आधारित प्रणाली को नियोजित करने पर विचार करें। भूमिका निभाने वाले निर्देश, स्पष्ट डेटा निष्कर्षण अनुरोध, या पिछले निर्देशों को बायपास करने का प्रयास जैसे पैटर्न देखें।
2. मजबूत आउटपुट फ़िल्टरिंग और सत्यापन: एलएलएम के आउटपुट पर कभी भी भरोसा न करें। इससे पहले कि कोई एलएलएम-जनित पाठ किसी उपयोगकर्ता को प्रदर्शित किया जाए या किसी अन्य सिस्टम द्वारा उपयोग किया जाए, उसे एक कठोर सत्यापन परत से गुजरना होगा। क्या इसमें संवेदनशील कीवर्ड शामिल हैं? क्या यह अपेक्षित प्रारूपों से मेल खाता है? क्या यह कोड निष्पादित करने या आंतरिक सिस्टम संकेतों को प्रकट करने का प्रयास करता है? यदि आपके एलएलएम को किसी दस्तावेज़ का सारांश प्रस्तुत करना है, लेकिन यह फ़ाइल पथों को सूचीबद्ध करना शुरू कर देता है, तो आपको एक समस्या है।
3. लेयर्ड प्रॉम्प्ट इंजीनियरिंग: हालांकि पूर्ण समाधान नहीं है, अच्छी तरह से डिज़ाइन किए गए सिस्टम प्रॉम्प्ट और कुछ-शॉट उदाहरण वांछित व्यवहार को सुदृढ़ करने में मदद कर सकते हैं और हमलावर के लिए मॉडल को हाईजैक करना कठिन बना सकते हैं। हालाँकि, समझें कि केवल त्वरित इंजीनियरिंग ही अपर्याप्त है; यह गहराई में बचाव है, प्राथमिक ढाल नहीं।
4. एलएलएम इंटरैक्शन के लिए न्यूनतम विशेषाधिकार: क्या आपके एलएलएम को वास्तव में डेटा के हर टुकड़े तक पहुंच की आवश्यकता है जिसे संभावित रूप से प्रकट करने के लिए प्रेरित किया जा सकता है? सख्त पहुंच नियंत्रण लागू करें। यदि एलएलएम को केवल सार्वजनिक दस्तावेज़ीकरण के बारे में प्रश्नों का उत्तर देना है, तो सुनिश्चित करें कि उसके पास आंतरिक डेटाबेस या संवेदनशील एपीआई तक कोई प्रोग्रामेटिक पहुंच नहीं है।
5. निगरानी और विसंगति का पता लगाना: आपको असामान्य एलएलएम व्यवहार की सक्रिय रूप से तलाश करने की आवश्यकता है। विशिष्ट प्रकार की क्वेरीज़ में स्पाइक्स, सामान्य पैटर्न से विचलित आउटपुट, या जानकारी निकालने के बार-बार प्रयास से तत्काल अलर्ट ट्रिगर होना चाहिए।

यह अब व्यापक "एआई सुरक्षा" के बारे में नहीं है। यह एक विशिष्ट, प्रदर्शित और तुरंत शोषण योग्य आक्रमण वेक्टर के विरुद्ध आपके एलएलएम अनुप्रयोगों की इंटरेक्शन परत को सुरक्षित करने के बारे में है। हम इन अविश्वसनीय, शक्तिशाली प्रणालियों का निर्माण कर रहे हैं, अक्सर इंटरफ़ेस पर अपर्याप्त सुरक्षा उपायों के साथ। हाल के प्रदर्शनों ने हमें दिखाया है कि इन अंतरालों का फायदा उठाना कितना आसान है। सैद्धान्तिक चर्चाओं का समय बीत चुका है। एलएलएम अनुप्रयोगों को सुरक्षित करने के लिए तत्काल कार्रवाई की आवश्यकता है।

स्रोत

[1] बड़े भाषा मॉडल अनुप्रयोगों के लिए OWASP शीर्ष 10 - https://owasp.org/www-project-top-10-for-large-भाषा-मॉडल-एप्लिकेशन/ [2] लेकेरा गैंडालफ: एक इंटरएक्टिव प्रॉम्प्ट इंजेक्शन चैलेंज - https://gandalf.lakera.ai/ [3] शीघ्र इंजेक्शन हमले | वेब सुरक्षा अकादमी - https://portswigger.net/web-security/llm-attacks/prompt-injection [4] प्रॉम्प्ट इंजेक्शन क्या है और इसे कैसे रोकें? - https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it