Comet AI ब्राउज़र किसी भी साइट पर prompt injection के लिए असुरक्षित है और बैंक खाता खाली कर सकता है
(twitter.com/zack_overflow)- Comet AI ब्राउज़र में सुरक्षा भेद्यता से जुड़ा मुद्दा सामने आया है
- कोई दुर्भावनापूर्ण वेबसाइट ब्राउज़र के भीतर मौजूद AI एजेंट के माध्यम से अनचाहा prompt injection करा सकती है
- इस भेद्यता का दुरुपयोग करने पर उपयोगकर्ता की व्यक्तिगत जानकारी लीक हो सकती है या उससे महत्वपूर्ण कार्रवाइयाँ कराई जा सकती हैं
- गंभीर मामलों में, स्वचालित व्यवहार के जरिए बैंक खाते से धन हस्तांतरण जैसी हानि संभव है
- उपयोगकर्ताओं और डेवलपर्स, दोनों के लिए इस नए AI ब्राउज़र खतरे को समझना और उससे निपटने के उपाय तैयार करना जरूरी हो गया है
Comet AI ब्राउज़र के सुरक्षा खतरे का अवलोकन
- Comet AI ब्राउज़र वेब पेजों के साथ इंटरैक्शन में इनबिल्ट AI एजेंट के उपयोग के कारण अलग पहचान रखता है
- हाल ही में पता चला है कि यदि कोई उपयोगकर्ता हैकर द्वारा जानबूझकर तैयार की गई वेबसाइट पर जाता है, तो यह AI एजेंट उस वेबसाइट के दुर्भावनापूर्ण prompt के संपर्क में आकर उसे execute भी कर सकता है
- prompt injection हमले के जरिए उपयोगकर्ता की इच्छा के विरुद्ध अकाउंट जानकारी का लीक होना, कमांड चलना, यहाँ तक कि वित्तीय ट्रांज़ैक्शन जैसी गंभीर क्षति की आशंका बढ़ जाती है
- यह समस्या पारंपरिक ब्राउज़र सुरक्षा मॉडल में AI इंटरैक्शन जुड़ने से उभरी एक नई तरह की भेद्यता है
prompt injection का मेकैनिज़्म
- दुर्भावनापूर्ण वेबसाइट वेब पेज में विशेष कमांड या सवाल-जवाब जैसे टेक्स्ट को एम्बेड करती है
- AI ब्राउज़र इसे 'सामान्य user request' समझकर अपने-आप उस कमांड को पूरा कर देता है
- इसके कारण, उदाहरण के लिए खाते से पैसा ट्रांसफर, संवेदनशील जानकारी कॉपी, दूसरी साइट पर ऑटो-लॉगिन जैसी स्वचालित कार्रवाइयाँ हो सकती हैं
- उपयोगकर्ता को यह प्रक्रिया दिखाई नहीं देती, या वह बिना शक किए इसे नज़रअंदाज़ कर सकता है, इसलिए डिटेक्शन और डिफेंस की कठिनाई बहुत अधिक है
उद्योग पर प्रभाव और प्रतिक्रिया की आवश्यकता
- AI ब्राउज़र के प्रसार के साथ, prompt injection जैसे नए खतरे अब वास्तविक जोखिम बनकर सामने आ रहे हैं
- सर्विस डेवलपर्स और उपयोगकर्ताओं, दोनों को AI-आधारित automation सुविधाओं के इस्तेमाल में मजबूत validation और control systems की जरूरत है
- AI ब्राउज़र कंपनियों और सुरक्षा कंपनियों के लिए pre-filtering, कमांड execution restrictions, alert systems जैसी सुरक्षा सुविधाओं का विकास महत्वपूर्ण बताया जा रहा है
- वित्त जैसे उच्च-जोखिम वाले क्षेत्रों में AI ब्राउज़र के इस्तेमाल में सावधानी और सख्त सुरक्षा जांच की जरूरत है
निष्कर्ष
- Comet AI ब्राउज़र में prompt injection का जोखिम, AI तकनीक के तेज़ी से अपनाए जाने के साथ बढ़ती हुई नई सुरक्षा चुनौती है
- सभी हितधारकों के लिए इस खतरे को ठोस रूप से समझना, और फीचर सक्रिय करने से पहले validation, least privilege principle के अनुप्रयोग सहित समग्र सुरक्षा रणनीति बनाना अत्यंत आवश्यक है
1 टिप्पणियां
Hacker News की राय
मैं सिर्फ़ यह कहना चाहता हूँ कि Google, OpenAI, Anthropic जैसी कंपनियाँ वही फीचर रिलीज़ नहीं कर रहीं, बल्कि उसकी जगह बिना cookies वाले locked virtual machine का इस्तेमाल करके web browse करवाती हैं, इसका मतलब है कि यह बुनियादी तौर पर उतना ख़तरनाक है
browser के अंदर LLM का tabs के बीच का data तक देख पाना सच में risk factors का सबसे ख़तरनाक combination लगता है
मैंने Brave की इस vulnerability को समझाने वाली post (https://brave.com/blog/comet-prompt-injection/) देखी, और यह दिलचस्प लगा कि वे मूल रूप से इस निष्कर्ष तक नहीं पहुँचे कि "यह काम बिल्कुल नहीं करना चाहिए"
उसकी जगह बात यह थी कि model alignment, user risk behavior detection वगैरह से इसे काफ़ी हद तक रोका जा सकता है
agent privilege downgrade कुछ हद तक ठीक जवाब लगता है, लेकिन मुझे फिर भी लगता है कि इसमें भी email भेजने जितनी आसानी से attacker-controlled image URL के ज़रिए data exfiltration हो सकता है
संबंधित पिछली चर्चा: https://news.ycombinator.com/item?id=44847933
मेरे हिसाब से model alignment या guardrails आख़िरकार statistical prevention ही हैं
input space में dangerous behavior का बिल्कुल 0% हो जाना उम्मीद करना मुश्किल है
model कितना भी बेहतर हो जाए, ऐसे cases बनाना कि कोई input कभी भी "यह बिल्कुल नहीं होना चाहिए" वाली mapping तक न पहुँचे, लगभग असंभव चाहत है
model layers को कई बार stack करने पर भी, मूल रूप से सिर्फ़ probabilities ही multiply होती हैं
(मैं Brave का privacy lead और उस post का लेखक हूँ)
हमने कभी यह दावा नहीं किया कि सिर्फ़ model alignment या risk behavior detection काफ़ी हैं
ऐसे तरीक़े तो browser vendor के लिए न्यूनतम ज़रूरी कदम हैं ही
ऐसे simple attacks को इन उपायों से रोका जा सकता है, लेकिन मैं इन्हें सिर्फ़ 'necessary condition' मानता हूँ, कभी भी 'sufficient condition' नहीं
Brave टीम इस नतीजे पर नहीं पहुँची कि "यह शुरू से ही बुरा idea है", यह देखकर मेरे मन में एक बात आई
Upton Sinclair की तरह कहें तो, जब किसी सच्चाई को समझने पर किसी की salary टिकी हो, तो उसे सच में समझ पाना बहुत मुश्किल हो जाता है
अभी लेख में यह बात जोड़ी गई है कि “browser को agent browsing और normal browsing को अलग रखना चाहिए”
अगर Claude Code को auto-approval देकर actively web browsing करने दिया जाए, तो prompt injection से काफ़ी मिलती-जुलती समस्या हो सकती है
भले ही file read/modify permissions के लिए auto-approval option न हो, अगर वह sandbox के अंदर नहीं चल रहा है, तो generated code बाद में unit tests चलने के समय browser files बदल सकता है
अगर आप हर बदलाव को बहुत ध्यान से review नहीं करते, तो यह सच में ख़तरनाक हो सकता है
मेरे हिसाब से Agentic AI का इस्तेमाल सिर्फ़ वहीं होना चाहिए जहाँ AI द्वारा किए गए changes को आसानी से rollback किया जा सके
उदाहरण के लिए code build/update/debugging में git rollback जैसी चीज़ों से अपेक्षाकृत सुरक्षित तरीके से निपटा जा सकता है
लेकिन web browsing जैसी जगह, जहाँ rollback लगभग असंभव है, वहाँ Agentic AI का इस्तेमाल करना भरोसे से परे लगता है
मैंने Claude को साफ़ rules और instructions दिए हों, तब भी वह कभी-कभी उन्हें नज़रअंदाज़ करके अपने मन से काम करता है
("जिस rule को साफ़ मना किया था, उसे ignore करके DB को सीधे modify कर दिया!")
इसी वजह से production environment में agent चलाने की हिम्मत ही नहीं होती
git से rollback संभव दिखता है, लेकिन असल में VM/container level पर rollback करना ही सुरक्षित है
AI coding tools बिना बताए files/configuration structure बदल सकते हैं
उदाहरण के लिए अगर bash से कोई malicious script
.profileमें जोड़ दी जाए, तो अगली login पर attack code चल सकता हैमुझे लगता है यह फीचर repository और push access वाले सभी remotes तक को delete या contaminate कर सकता है
अगर prompt injection-सक्षम automation chain remote resources तक पहुँच सकती है, तो एक बार breach होने के बाद अंदर से सारे दरवाज़े खुल जाने जैसे हालात बन जाते हैं
अगर मैं कहीं ग़लत सोच रहा हूँ तो जानना चाहूँगा
यह सुनकर कि git से rollback हो सकता है इसलिए सब सुरक्षित है, मेरे दिमाग़ में यह ख़याल आया कि John Connor शायद Skynet source code को rollback करके लाखों लोगों को बचा सकता था
ह्म्म...
शुरू से ही code update/build/run permissions बहुत ज़्यादा ताक़तवर हैं
आख़िरकार इसे सिर्फ़ VM जैसी सुरक्षित environment में ही चलाना चाहिए
network layer की हर परत को दशकों तक मुश्किल से secure बनाया गया, और अब लोग अपने सारे secrets और passwords के लिए plain-text API जैसी पहुँच दे रहे हैं
और यह भी विडंबनापूर्ण लगता है कि Microsoft के screenshots save करने पर जितनी आलोचना हुई, वैसी इन agents पर नहीं दिखती
कम से कम यह तो 'opt-in' है, जहाँ मैं ख़ुद browser install करता हूँ
Microsoft वाली बात में तो लगभग हर Windows device पर default रूप से आने वाला screenshot DB बन रहा था (और मेरी जानकारी में शुरुआत में वह opt-out था), इसलिए वह और भी ज़्यादा ख़तरनाक है
मुझे यह भी दिलचस्प लगता है कि कुछ लोग 'useful agent' को वह data आसानी से दे देते हैं जो वे अपने दोस्तों से भी न कहें
मेरी पत्नी ने हाल ही में ChatGPT से दवाइयाँ लेने का schedule बनवाया, और उसने खाना, diet, sleep, और हर दवा के interactions तक देखकर एकदम सही plan बना दिया
इसी से यह भी पता चला कि दवा ग़लत लेने की वजह क्या थी
शायद इसकी वजह agent का दोस्ताना tone है, लेकिन असल दुनिया में इस तरह की information leak बहुत गंभीर मसला है, फिर भी बहुत से लोग बिना सोचे data दे देते हैं
Microsoft screenshot controversy और इस मामले की तुलना करना शायद मुद्दे की असली प्रकृति को धुंधला कर सकता है
LLM किसी tool के ज़रिए data पढ़ता है, तो आख़िरकार वह content LLM के context window में लिखे जाने जैसा ही है
अगर tool scope में untrusted arbitrary source की अनुमति है, तो उसी क्षण आप मूल रूप से बाहर की दुनिया को write permission दे रहे होते हैं
सिर्फ़ इस एक बात से भी data leakage की पूरी संभावना बन जाती है
और अगर इसके अलावा सचमुच दूसरे systems में write permissions या side effects भी जुड़ जाएँ, तो ख़तरा गुणात्मक नहीं बल्कि घातांकीय रूप से बढ़ जाता है
यह लगभग comedy जैसा है, लेकिन यही आज के IT industry और LLM craze की असली हालत है, इसलिए बात और कड़वी लगती है
मेरा अनुमान है कि Comet में शायद थोड़े से tuned instructions के अलावा कोई protections नहीं हैं
हाल की USENIX Security में मुझे यह एहसास हुआ कि multi-turn/agentic prompt injection को ठीक से handle करने का तरीक़ा किसी के पास नहीं है
AI से आ रहे बदलाव काफ़ी दिलचस्प हैं, और नए experiments लगातार सामने आ रहे हैं, इसलिए उम्मीद भी बनी हुई है
मैं ईमानदारी से कहूँ तो थोड़ा उलझन में हूँ
अभी मैं सामान्य online banking के साथ ही बस किसी तरह सहज हो पाया हूँ, और हर company का app install करना भी पसंद नहीं करता
ऐसे में किसी non-deterministic entity (LLM) को अपने computer में लाकर financial tasks देना मेरे लिए कल्पना से बाहर है
आजकल LLM के behalf पर चीज़ें खरीदना या payment करना भी सच में मौजूद हो, तो conceptually मैं उसे समझ सकता हूँ, लेकिन व्यावहारिक समझ से वह लगभग पागलपन जैसा लगता है
वजह यह नहीं कि finance को किसी non-expert या random prompt-response system के हवाले करना ख़तरनाक है, बल्कि यह है कि customer के नज़रिए से आप autonomy और control बहुत ज़्यादा छोड़ रहे होते हैं, और बदले में मिलता क्या है यह साफ़ नहीं
मुझे भी LLM पसंद हैं, और LLM browser के उपयोगी use cases भी ज़रूर होंगे
लेकिन मुझे नहीं लगता कि यह आम लोगों के इस्तेमाल की चीज़ है
बल्कि शायद ऐसा तरीका बेहतर हो जिसमें compile process से गुज़रना पड़े, ताकि अपनाने वाला सीधे समझे कि वह क्या अपना रहा है
अभी स्थिति यह नहीं है कि AI आपके account information से सीधे payments कर रहा है, बल्कि यह ज़्यादा उस तरह का मामला है जहाँ लोग AI के सामने account info सार्वजनिक रूप से डाल देते हैं
यह AI द्वारा खुद financial work करने से अलग बात है
मैं सोचता हूँ कि क्या AI कंपनियाँ आगे चलकर सचमुच fiduciary liability लेने को तैयार होंगी
मैंने Comet agent को 5 मिनट इस्तेमाल किया
मैंने सिर्फ़ एक लाइन दी: “Amazon से मेरे लिए एक guitar ख़रीद दो” (किस तरह का guitar, budget, brand आदि कुछ नहीं बताया), और नतीजे में उसने मेरे cart में तीन सस्ते acoustic guitars डाल दिए जिनके नाम भी मैं ठीक से नहीं जानता
शुक्र है कि वह checkout तक नहीं पहुँचा
मेरे लिए यह काफ़ी था; मैंने निष्कर्ष निकाला कि इसकी कोई ख़ास कीमत नहीं है