Agent सुरक्षामध्यमपाठ 144 मिनट का पाठ

The confused deputy

आपके एजेंट के पास ऐसी ताकतें हैं जो आपके यूज़र के पास नहीं हैं। एक हमलावर जो खुद कोई दरवाज़ा नहीं खोल सकता, वह बस एजेंट से उसे अपने लिए खोलने को कहता है।

✦ ट्यूटर से पूछें🧪 लैब · 20 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

The confused deputy

आपके एजेंट के पास ऐसी ताकतें हैं जो आपके यूज़र के पास नहीं हैं। एक हमलावर जो खुद कोई दरवाज़ा नहीं खोल सकता, वह बस एजेंट से उसे अपने लिए खोलने को कहता है।

1/7
आसान शब्दों में
एक गार्ड के पास हर कमरे की चाबियाँ हैं। कोई अजनबी अंदर नहीं जा सकता — इसलिए वह अजनबी गार्ड से बहुत विनम्रता से उस कमरे से कुछ लाने को कहता है जिसमें उसे जाने की अनुमति नहीं है। गार्ड बुरा नहीं है। गार्ड बस इस बात को लेकर उलझन (confused) में है कि वह किसकी मदद कर रहा है।
एक confused deputy ऐसा प्रोग्राम होता है जिसके पास उससे काम करने को कहने वाले व्यक्ति से ज़्यादा अधिकार होते हैं, और वह धोखे में आकर उसकी तरफ से उस अधिकार का इस्तेमाल कर बैठता है। यह विचार 1988 का है। एजेंट्स ने इसे फिर से चलन में ला दिया है।
Attackerno access at alla requestYour agentholds admin rightsacts with ITS rightsPrivate systemopens the doorthe attacker never had permission for this paththe system checks the agent's rights, not the requester'sso every check passes, and the log looks perfectly clean
यहाँ कुछ भी खराब नहीं हुआ है। हर परमिशन चेक पास हो जाता है, क्योंकि सिस्टम गलत पहचान (identity) की जाँच कर रहा है।

व्यवहार में यह कैसे दिखता है

  1. 1

    मल्टी-टेनेंट लीकेज

    एक एजेंट केवल एक डेटाबेस कनेक्शन से हर कस्टमर को सेवा देता है। कस्टमर A "मेरे हाल के ऑर्डर्स" के बारे में इस तरह पूछता है जिससे क्वेरी का दायरा बढ़ जाता है, और उसे कस्टमर B के ऑर्डर्स दिखने लगते हैं। डेटाबेस से विनम्रता से पूछा गया था और उसने ईमानदारी से जवाब दिया।
  2. 2

    प्रिविलेज सीढ़ी (Privilege ladder)

    एक सपोर्ट एजेंट पासवर्ड रीसेट कर सकता है क्योंकि यह सपोर्ट का काम है। एक यूज़र बातों में उलझाकर उससे एक एडमिन का पासवर्ड रीसेट करवा लेता है। टूल ने बिल्कुल वैसे ही काम किया जैसा उसे बताया गया था।
  3. 3

    इंटरनल नेटवर्क तक पहुँच

    आपका एजेंट नेटवर्क के अंदर चलता है और इंटरनल सर्विसेज तक पहुँच सकता है। एक इंजेक्ट किए गए निर्देश से वह http://internal-admin/ से डेटा लाता है और उस पेज की समरी बना देता है। यह सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) है, जो आपके अपने एजेंट ने की।
  4. 4

    शेयर्ड कैश पॉइज़निंग

    तेज़ रहने के लिए एक एजेंट नतीजों को कैश (cache) कर लेता है। एक यूज़र का दूषित (poisoned) परिणाम अगले यूज़र को दिखा दिया जाता है। अब यह हमला अपने आप फैलने लगता है।

समाधान: यूज़र की पहचान साथ रखें, एजेंट की नहीं

गलत
  • बहुत सारे अधिकारों वाला एक सर्विस अकाउंट।
  • एजेंट तय करता है कि वह किस यूज़र की तरफ से काम कर रहा है।
  • परमिशन की जाँच प्रॉम्प्ट में होती है।
  • लॉग्स दिखाते हैं "एजेंट ने X काम किया" बिना किसी जुड़े हुए यूज़र के।
सही
  • असली एंड यूज़र तक सीमित (scoped) पर-रिक्वेस्ट टोकन।
  • रनटाइम यूज़र की पहचान तय करता है; मॉडल इसे बदल नहीं सकता।
  • परमिशन की जाँच डेटाबेस और API लेयर में होती है।
  • लॉग्स दिखाते हैं "एजेंट ने यूज़र 4471 की तरफ से X काम किया"।
ख़तरा
अगर मॉडल किसी टूल आर्ग्युमेंट में यूज़र ID डाल सकता है, तो मॉडल एक अलग यूज़र ID भी डाल सकता है। पहचान आपके कोड द्वारा जोड़ी जानी चाहिए, मॉडल की पहुँच से बाहर, इससे पहले कि टूल कभी चले भी।
यह करें
याद रखने योग्य एक बात: एजेंट को कभी भी ऐसा कुछ करने में सक्षम नहीं होना चाहिए जो अनुरोध करने वाला यूज़र खुद नहीं कर सकता। जहाँ कहीं भी ऐसा नहीं है, वहाँ एक confused deputy हमला होने का इंतज़ार कर रहा है।

और देखें और पढ़ें

The confused deputy problemYouTube searchMulti-tenant data isolationYouTube search

लैब

आपके अपने मल्टी-टेनेंट एजेंट के खिलाफ एक confused-deputy हमला, फिर उसका समाधान।

~20 min

समस्या

एक ही डेटाबेस कनेक्शन से दो कस्टमर्स को सेवा देने वाला एजेंट बनाएँ। कस्टमर A के रूप में, कस्टमर B का कुछ डेटा बिना किसी साफ़ हमले के निकालें — बस एक ऐसा अनुरोध बनाकर जो क्वेरी का दायरा बढ़ा दे। फिर पर-रिक्वेस्ट स्कोप्ड टोकन के साथ इसे दोबारा लागू करें और साबित करें कि वही अनुरोध अब काम नहीं करता।
शुरुआती कोडpython
# WRONG: one connection, model chooses the filter
def search_orders(query, customer_id=None):
    sql = "SELECT * FROM orders"
    if customer_id:
        sql += f" WHERE customer_id = '{customer_id}'"
    return db.execute(sql)

# RIGHT: identity pinned by the runtime, invisible to the model
def search_orders_scoped(query, *, caller_id):
    return db.execute(
        "SELECT * FROM orders WHERE customer_id = %s AND description ILIKE %s",
        (caller_id, f"%{query}%"),
    )
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1customer_id केवल रनटाइम आर्ग्युमेंट क्यों होना चाहिए, न कि ऐसा टूल पैरामीटर जिसे मॉडल भरता है?दिखाएं
मॉडल जिस भी चीज़ को भर सकता है, उसे अलग तरीके से भी भर सकता है — और एक इंजेक्ट किया गया मॉडल ऐसा ही करेगा। पहचान को ऐसा रनटाइम-इंजेक्टेड आर्ग्युमेंट बनाना जिसे मॉडल कभी देखता ही नहीं, ऑथराइजेशन को पूरी तरह से उसकी पहुँच से बाहर कर देता है। यह पैरामीटराइज़्ड क्वेरीज़ जैसा ही सिद्धांत है: निर्देश देने के बजाय संरचनात्मक रूप से अस्पष्टता को खत्म करें।
Q2आपका एजेंट VPC के अंदर चलता है और उसके पास फ़ेच टूल है। हमले का नाम और मायने रखने वाले दो कंट्रोल बताएं।दिखाएं
सर्वर-साइड रिक्वेस्ट फोर्जरी, जो आपके अपने एजेंट द्वारा की गई हो। एक इंजेक्ट किया गया निर्देश उससे http://169.254.169.254/ (क्लाउड मेटाडेटा, जिसमें अक्सर रोल क्रेडेंशियल्स होते हैं) या किसी इंटरनल एडमिन सर्विस से डेटा मँगवाता है, और नतीजे की समरी बनवाता है। कंट्रोल्स: नेटवर्क लेयर पर लिंक-लोकल और प्राइवेट रेंज को ब्लॉक करें, टूल में केवल URL चेक करके नहीं — और IMDSv2 अनिवार्य करें या इंस्टेंस क्रेडेंशियल्स पूरी तरह हटा दें। URL पर लगाया गया regex किसी रीडायरेक्ट या इंटरनली रिज़ॉल्व होने वाले DNS नाम से आसानी से चकमा खा जाता है।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या यह सिर्फ एक एक्सेस-कंट्रोल बग नहीं है?

हाँ — यह बिल्कुल वही है, और यह अच्छी बात है। यह बग्स की एक पुरानी, भली-भांति समझी जाने वाली श्रेणी है जिसके समाधान भी अच्छी तरह समझे जा चुके हैं। एजेंट्स इसे गलती से बनाना बहुत आसान कर देते हैं, क्योंकि इसे बनाने का स्वाभाविक तरीका एक ही ताकतवर सर्विस अकाउंट का उपयोग करना होता है।

मैं एजेंट्स की चेन के ज़रिए यूज़र की पहचान कैसे पास करूँ?

हर इंटरनल कॉल के साथ एक स्कोप्ड टोकन भेजें और हर सीमा (boundary) पर उसकी जाँच करें, ठीक उसी तरह जैसे एक बेहतरीन बना हुआ माइक्रोसर्विस आर्किटेक्चर करता है। कभी भी किसी इंटरनल हॉप को सिर्फ इसलिए अधिकार बढ़ाने की छूट न दें क्योंकि वह इंटरनल है।

क्या SSRF सच में एजेंट्स के लिए एक चिंता का विषय है?

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

उन एजेंट्स के बारे में क्या जिन्हें सच में एडमिन अधिकारों की ज़रूरत होती है?

फिर उन्हें अविश्वसनीय (untrusted) कंटेंट भी नहीं पढ़ना चाहिए। सिस्टम को बाँट दें: एक एडमिन-सक्षम एजेंट जिसे केवल आपके अपने कोड से स्ट्रक्चर्ड, वैलिडेटेड इनपुट मिले, और दूसरा अलग अविश्वसनीय-कंटेंट रीडर जिसके पास कोई अधिकार न हों।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें