عندما تتحول GPTs المخصصة إلى أبواب خلفية سحابية: اختراق ChatGPT SSRF ومستقبل أمن الذكاء الاصطناعي

إذا بقيت في مجال الأمن لفترة طويلة بما فيه الكفاية، فإنك في نهاية المطاف تطور عادة سيئة: تتوقف عن رؤية "الميزات" وتبدأ في رؤية مسارات الهجوم المحتملة. إن القصة الأخيرة حول "اختراق ChatGPT باستخدام GPTs المخصصة التي تستغل ثغرة في SSRF لفضح الأسرار" هي مثال نموذجي. ما بدا كميزة إجراءات ملائمة لـ GPTs المخصصة اتضح أنه نفق مباشرةً إلى بيئة السحابة الخاصة بـ OpenAI. لا يوجد سحر موجه غريب، ولا "سحر ذكاء اصطناعي" خاطئ - مجرد خطأ قديم جداً، تزوير الطلبات من جانب الخادم، أعيد اكتشافه داخل منصة جديدة جداً.

هذا هو بالضبط سبب أهمية هذه الحادثة. فهي ليست عنواناً آخر من عناوين الضجيج حول انحراف الذكاء الاصطناعي. بل هو تذكير بأنه بمجرد تضمين نماذج الذكاء الاصطناعي الخفي في بنية تحتية حقيقية، فإن القواعد التقليدية لأمن التطبيقات والسحابة تعود بقوة. قد تكون النماذج جديدة؛ لكن الأخطاء الكامنة ليست كذلك.

إعادة بناء الاستغلال: من "إضافة إجراء" إلى الرمز المميز السحابي

لفهم ما حدث، عليك أن تنظر إلى كيفية عمل GPTs المخصصة. تتيح لك واجهة OpenAI تحديد الإجراءات، والتي هي في الأساس واجهات برمجة تطبيقات HTTP خارجية يمكن لـ GPT الخاص بك استدعاؤها بناءً على مخطط OpenAPI. بالنسبة للمستخدمين، يبدو هذا الأمر وكأنه يمنح GPT الخاص بك "قوى خارقة": يمكنه جلب البيانات، وتشغيل سير العمل، والاتصال بالأنظمة الداخلية. تحت الغطاء، يعني ذلك وجود عميل HTTP خلفي، يعمل داخل البنية التحتية ل OpenAI، والذي سيستدعي بسعادة عناوين URL التي تصفها ويغذي الردود مرة أخرى في النموذج.

لاحظ باحث من Open Security هذا بالضبط. أثناء اللعب مع GPTs المخصصة GPTs، رأوا النمط المألوف: عناوين URL يتحكم بها المستخدم، وزر "اختبار" يرسل طلبات مباشرة، وخادم يعمل بوضوح داخل بيئة سحابية. سيتعرف أي شخص قام باختبار الاختراق السحابي على الغريزة التي تلي ذلك: تحقق مما إذا كان بإمكانك خداع هذا الخادم لاستدعاء عناوين داخلية نيابةً عنك. هذا هو جوهر SSRF.

في البيئات السحابية، يكون الهدف الداخلي الأكثر قيمة دائمًا هو خدمة البيانات الوصفية. على Azure، كما هو الحال في السحابة الأخرى، فهي موجودة على العنوان المحلي للرابط 169.254.169.254. من داخل جهاز افتراضي أو حاوية، يمكن لنقطة النهاية هذه الكشف عن تفاصيل حول المثيل، والأهم من ذلك، إصدار رموز قصيرة الأجل تسمح لأحمال العمل باستدعاء واجهات برمجة التطبيقات الخاصة بإدارة السحابة. من خارج السحابة، لا يمكنك الوصول إليها. هذا هو بالضبط السبب في أهمية SSRF: أنت تختطف نقطة نهاية الخادم وتجبره على التحدث إلى أشياء لا يمكنك كمهاجم خارجي الوصول إليها.

كانت العقبة الأولى التي واجهت الباحث هي أن إجراءات GPT المخصصة لا تسمح إلا بعناوين URL الخاصة بـ HTTPS، في حين أن خدمة البيانات الوصفية هي HTTP فقط. للوهلة الأولى يبدو هذا التقييد وكأنه دفاع، ولكن من الناحية العملية هو مجرد قطعة أحجية أخرى. كان الحلّ بسيطًا ومباشرًا: تسجيل نطاق HTTPS خارجي تحت سيطرة الباحث، وجعله يستجيب بإعادة توجيه 302 يشير إلى http://169.254.169.254 عنوان URL للبيانات الوصفية، ومعرفة ما إذا كانت الواجهة الخلفية للإجراءات تتبع إعادة التوجيه. لقد فعلت ذلك. فجأة، نتج عن مكالمة HTTPS ذات المظهر البريء في تكوين GPT المخصص استدعاء HTTP إلى نقطة نهاية البيانات الوصفية السحابية الداخلية.

ومع ذلك، فإن خدمة البيانات الوصفية في Azure ليست ساذجة تمامًا. لمنع إساءة الاستخدام العرضية، فهي تتطلب رأسًا خاصًا, البيانات الوصفية: صحيحفي كل طلب. إذا كان الرأس مفقودًا، ترفض الخدمة الكشف عن البيانات الحقيقية. في هذه المرحلة، قد يبدو أن النظام آمن مرة أخرى، لأن واجهة مخطط OpenAPI المستخدمة لتعريف الإجراءات لا تكشف عن تكوين رأس اعتباطي. ولكن نادراً ما يكون للأنظمة الكبيرة سطح تكوين واحد فقط. في هذه الحالة، تدعم ميزة الإجراءات أيضًا فكرة "مفاتيح واجهة برمجة التطبيقات" ورؤوس المصادقة الأخرى التي يمكنك تحديدها عند توصيل خدمة خارجية. ثم يتم إرفاق هذه الرؤوس تلقائيًا بالطلبات الصادرة.

كان ذلك كافياً لإكمال السلسلة. من خلال تعريف "مفتاح API" مزيف كان اسم رأسه حرفيًا البيانات الوصفية والتي كانت قيمتها صحيحأقنع الباحث الواجهة الخلفية بتضمين العنوان الدقيق الذي يتوقعه Azure IMDS. ادمج ذلك مع حيلة إعادة التوجيه وستحصل الآن على قناة SSRF من الواجهة الخلفية لإجراءات GPT المخصصة إلى خدمة البيانات الوصفية، مع البيانات الوصفية: صحيح الرأس.

بمجرد إنشاء هذه القناة، كان الباقي ميكانيكيًا تقريبًا. طلب الباحث من خدمة البيانات الوصفية الحصول على رمز OAuth2 المخصص لواجهة برمجة تطبيقات إدارة Azure، باستخدام مسار IMDS المعروف. احتوى الرد على رمز وصول مرتبط بالهوية السحابية التي تستخدمها البنية التحتية ChatGPT. يمكن لهذا الرمز المميز، على الأقل، الاستعلام عن نقاط نهاية الإدارة وربما الوصول إلى الموارد الحساسة، اعتمادًا على مقدار الامتيازات التي تتمتع بها الهوية. عند هذه النقطة، توقف الباحث، وأبلغ عن النتائج من خلال برنامج مكافأة الأخطاء في OpenAI، وصنفت OpenAI الخلل على أنه عالي الخطورة وتحركت لتصحيحه.

ما يجعل هذه السلسلة ملفتة للنظر هو أن المهاجم لم يكن بحاجة إلى الوصول إلى shell، أو شفرة المصدر، أو أي خطأ كلاسيكي في مكدس HTTP. كل شيء حدث داخل شاشات التكوين العادية: عناوين URL، وإعدادات المصادقة، وزر اختبار قام بتنفيذ الأذى بشكل مطيع.

رسم تخطيطي برمجي صغير لمسبار على غرار SSRF

لجعل هذا الأمر أكثر واقعية، تخيل برنامج نصي مساعد داخلي صغير جدًا قد يستخدمه مهندس الأمن لفحص سلامة عميل HTTP "على غرار الإجراءات". الهدف ليس الوصول إلى خدمات البيانات الوصفية الحقيقية في الإنتاج، ولكن تقنين عادة سبر عمليات إعادة التوجيه غير المتوقعة والقفزات الداخلية لبروتوكول الإنترنت في بيئات التدريج أو المختبر:

استيراد الطلبات
من urllib.parse.parse استيراد urljoin

def trace_request(base_url: str، path: str = "/"):
    url = urljoin(url(base_url, path)
    طباعة(f"[+] طلب {url}")
    حاول
        resp = requests.get(url، المهلة=3، السماح بإعادة التوجيه=صحيح)
    باستثناء الاستثناء كـ e:
        طباعة (f"[!] خطأ: {e}")
        إرجاع

    طباعة(f"[+] عنوان URL النهائي: {resp.url}")
    طباعة(f"[+] الحالة: {resp.status_code.status_code}")
    طباعة("[+] سلسلة إعادة التوجيه:")")
    بالنسبة إلى h في resp.history:
        طباعة(f"[+] رمز الحالة: {h.status_code} -> {h.headers.get('Location'})")

    # إرشادات تقريبية جدًا: التحذير إذا وصلنا إلى عنوان IP داخلي
    إذا كان resp.resp.raw._connection و hasattr(resp.resp.raw._connection, "sock"):
        نظير = resp.resp.raw._connection.sock.getpeername()[0]
        طباعة (و"[+] عنوان IP الخاص بالنظير: {النظير}")
        إذا كان peer.startswith("10.") أو peer.startswith("192.168.") أو peer.startswith("169.254.")
            طباعة("[!] تحذير: اتبعت الواجهة الخلفية إعادة توجيه إلى عنوان داخلي")

إذا __name__ = = "__main____":
    # مثال: استبدل بنقطة نهاية اختبار محكومة في مختبرك الخاص
    trace_request("")

لا يقوم برنامج نصي كهذا "باستغلال ChatGPT"، ولكنه يلتقط نفس الشكل الاستقصائي: ابدأ من عنوان URL خارجي يُفترض أنه آمن، واتبع عمليات إعادة التوجيه، واشتكي بصوت عالٍ إذا وجد عميل HTTP نفسه فجأة يتحدث إلى نطاقات IP داخلية أو نطاقات IP محلية الارتباط. إن تحويل هذا النمط إلى أتمتة - وتشغيله ضد المكونات التي تشغل إجراءات الذكاء الاصطناعي الخاصة بك - أكثر فائدة بكثير من مجرد قراءة الحادث.

إنه ليس "خطأ في الذكاء الاصطناعي"؛ إنه إساءة استخدام السحابة القديمة على مرحلة جديدة

من المغري جدًا قراءة هذا الأمر على أنه "تم اختراق ChatGPT" والمضي قدمًا. هذا التأطير يغفل الدرس الأعمق. لا شيء في النموذج نفسه أساء التصرف. لم يكن هناك أي موجه يفتح بطريقة ما القدرات المحظورة. قام LLM بما طُلب منه: استدعاء إجراء، وقراءة النتيجة، وتلخيصها. عاشت الثغرة بالكامل في الغراء بين LLM والعالم الخارجي.

هذا الغراء هو بالضبط المكان الذي تحتاج فرق الأمان إلى نقل تركيزها إليه. عندما تمنح واجهة برمجة التطبيقات القدرة على استدعاء الأدوات أو الإجراءات أو المكونات الإضافية، فإنك تحوّلها فعلياً إلى عميل قابل للبرمجة في بنيتك التحتية. في الماضي، كان المستخدم يتصل يدويًا بواجهة برمجة التطبيقات الخاصة بك، وكنت تقوم بمراجعة مدخلاته. الآن، يقوم المستخدم بإعطاء تعليمات إلى نموذج، ويقوم النموذج بترجمة ذلك إلى مكالمات واجهة برمجة التطبيقات نيابةً عنه. يصبح النموذج طريقة أخرى لوصول النوايا العدائية إلى الواجهة الخلفية الخاصة بك.

من خلال هذه العدسة، فإن هذا الحادث هو ببساطة OWASP SSRF في زي مختلف. جميع الظروف مألوفة: عناوين URL المتأثرة بالمستخدم، وخادم يمكنه الوصول إلى نقاط النهاية الداخلية أو المميزة، وعناصر تحكم الخروج المفقودة أو غير المكتملة، وخدمة بيانات وصفية سحابية يمكن الوصول إليها بشكل كبير من أعباء العمل العادية. يكمن الاختلاف في أن نقطة الدخول لم تعد نموذج ويب كلاسيكي أو حقل JSON؛ بل هي كتلة تهيئة تم تصميمها لجعل GPTs المخصصة أكثر قوة.

وهذا أيضًا سبب أهمية نصف قطر الانفجار. لم يكن الخادم المتأثر خدمة مصغرة عشوائية؛ بل كان جزءاً من البنية التحتية متعددة المستأجرين الخاصة بـ ChatGPT، الموجودة داخل بيئة Azure الخاصة بـ OpenAI. كان أي رمز مميز تم الحصول عليه عبر IMDS ينتمي إلى عبء عمل كان لديه بالفعل وصول مفيد. حتى لو حدّت الدفاعات المحلية مما يمكن أن يفعله المهاجم، فإن ملف تعريف المخاطر يختلف اختلافاً جوهرياً عن جهاز افتراضي اختباري منسي.

الذكاء الاصطناعي كمحور تكامل: توسيع نطاق الهجوم وتحريك حدود الثقة

القصة الأكثر إثارة للاهتمام وراء هذا الخلل هي الهندسة المعمارية. فمنصات الذكاء الاصطناعي تتحول بسرعة إلى محاور تكامل. قد يتحدث GPT المخصص لفريق المبيعات إلى نظام إدارة علاقات العملاء، ونظام الفوترة، ومخزن المستندات. قد يتحدث GPT الذي يركز على الأمان إلى الماسحات الضوئية، وأنظمة إصدار التذاكر، و CI/CD. في كل حالة، لا تكون أداة الربط LLM هي الأصل؛ بل البيانات والإجراءات الكامنة وراء تلك الوصلات.

بمجرد قبولك لهذا الواقع، يجب أن يتغير نموذج التهديد الذهني الخاص بك. لا يمكنك الاستمرار في التفكير في "أمن الذكاء الاصطناعي" على أنه مجرد حقن موجه أو تسرب للبيانات أو مخرجات سامة. عليك أيضًا أن تسأل أسئلة غير براقة للغاية حول حدود الشبكة والهوية السحابية وعزل المستأجرين.

ما الذي يمكن للبنية التحتية التي تدير الإجراءات الخاصة بك التحدث إليه بالفعل على الشبكة؟ الإعداد الافتراضي في العديد من البيئات السحابية هو "أي شيء صادر مسموح به طالما أن نظام أسماء النطاقات DNS يحلها". كان ذلك منطقيًا عندما كانت الخدمات بسيطة نسبيًا وأراد المهندسون المرونة. ومع ذلك، ضع منصة LLM في المنتصف، وفجأة أصبح لدى كل مستأجر طريقة لاقتراح وجهات صادرة جديدة من خلال التكوين، بدلاً من التعليمات البرمجية. إذا لم تكن هناك سياسة خروج قوية، فقد أنشأت بشكل فعال مشغل SSRF قابل للبرمجة.

ما مقدار الامتيازات التي تتمتع بها الهويات التي تستخدمها أعباء العمل هذه؟ في حالة ChatGPT، تمكن الباحثون من طلب رمز مميز لواجهة برمجة تطبيقات Azure Management API. حتى لو كان هذا الرمز المميز مقيداً بتخصيصات الأدوار، فإنه لا يزال يمثل سراً عالي القيمة. في العديد من المؤسسات، يكون الإغراء بمنح "البنية التحتية للمنصة" أذونات واسعة النطاق قويًا، لأنه يبسط عملية النشر. بالنسبة لأي شيء يمكن أن يكون مدفوعًا بشكل غير مباشر من خلال مدخلات المستخدم - خاصةً من خلال الذكاء الاصطناعي - فإن هذا الإغراء خطير.

أين هي بالضبط حدود الثقة بين المستأجرين، وبين مستوى التحكم ومستوى البيانات، وبين وقت تشغيل الذكاء الاصطناعي وبقية السحابة؟ يجب أن يفترض النظام المصمم جيدًا أن تكوين أي مستأجر واحد يمكن أن يصبح عدائيًا، وأن أي مكالمة صادرة نيابةً عن ذلك المستأجر قد تكون عدائية، وأن أي ترقية من العمل إلى البيانات الوصفية إلى واجهات برمجة التطبيقات الإدارية هي هدف واقعي للمهاجمين. هذا المنظور يجعل أنماطاً مثل التجزئة الصارمة للشبكة، والسيارات الجانبية المصاحبة التي تفرض السياسات، وهويات الخدمة المخصصة غير قابلة للتفاوض بدلاً من أن تكون "لطيفة".

من حادثة واحدة إلى منهجية اختبار قابلة للتكرار

بالنسبة للمدافعين والبناة فإن القيمة الحقيقية لهذه القصة لا تكمن في الخطأ المحدد؛ بل في عقلية الاختبار التي توضحها. لقد تعامل الباحث بشكل أساسي مع إجراءات GPT المخصصة كنوع جديد غريب من عملاء HTTP، ثم سار من خلال قائمة مراجعة مألوفة: هل يمكنني التحكم في عنوان URL، هل يمكنني الوصول إلى المضيفين الداخليين، هل يمكنني إساءة استخدام عمليات إعادة التوجيه، هل يمكنني حقن الرؤوس، هل يمكنني ضرب البيانات الوصفية، هل يمكنني تحويل ذلك إلى رمز سحابي؟

إن قائمة المراجعة الذهنية هذه هي بالضبط ما يجب أن يكون مؤتمتاً داخل عمليات سير عمل اختبار الاختراق الحديثة لمنصات الذكاء الاصطناعي. فبدلاً من انتظار عناوين الأخبار وتقرير المكافآت، يجب أن تقوم الفرق بتحويل البنية التحتية المخصصة لاختبار الاختراق GPT، وأنظمة المكونات الإضافية، وسلاسل الأدوات إلى أهداف بشكل روتيني.

لجعل ذلك أكثر واقعية بعض الشيء، يمكنك التفكير في "مراجعة إجراءات الذكاء الاصطناعي لإطار عمل SSRF" على أنها تسلسل بسيط قابل للتكرار مثل هذا:

بمجرد أن يكون لديك هذا النوع من الجداول المكتوبة لبيئتك، يصبح من الأسهل بكثير أتمتة الاختبار الذي تقوم به وشرحه. يمكنك توصيله في كتب التشغيل الداخلية، ومشاركته مع البائعين، والتأكد من أن ميزات الذكاء الاصطناعي المستقبلية ستخضع لنفس المعيار.

هذا هو المكان الذي تبدأ فيه أهمية الأدوات الأمنية المتخصصة المدركة للذكاء الاصطناعي. قد لا يعرف الماسح الضوئي العام للويب كيفية التنقل في واجهة المستخدم التي تخفي مكالمات الشبكة خلف الإجراءات أو كيفية التفكير في مخططات OpenAPI المستخدمة داخل تعريف GPT. في المقابل، يمكن لمنصة اختبار خماسية تعتمد على الذكاء الاصطناعي مثل Penligent أن تتعامل مع تلك المخططات والتكوينات كمدخلات من الدرجة الأولى. يمكنك أن تتخيل سير عمل حيث يمكنك تصدير تكوين الإجراءات لمجموعة من GPTs المخصصة أو غيرها من أدوات الذكاء الاصطناعي الأخرى، وتغذيتها في خط أنابيب اختبار عميل والسماح لها بالتحقق بشكل منهجي من شروط SSRF، وعمليات إعادة التوجيه غير الآمنة، والوصول غير المحدود إلى الشبكة، والتعرض للبيانات الوصفية.

تتناسب فلسفة Penligent في الجمع بين الأتمتة والتحكم البشري في الحلقة مع هذا النمط بشكل جيد. يمكن للوكيل تعداد جميع تعريفات الأدوات، وإنشاء حمولات مرشحة لنقاط النهاية التي تقبل عناوين URL أو أسماء المضيفين، وتوجيه حركة مرور مكتوبة تحاكي ما قد يحاول المهاجم الفضولي تجربته. وبمجرد أن يكتشف النظام سلوكًا واعدًا - على سبيل المثال، أن نقطة نهاية HTTPS خارجية على ما يبدو تتبع عمليات إعادة توجيه إلى نطاقات IP داخلية - يمكنه إظهار ذلك كدليل: سجلات الطلبات، ومقتطفات الاستجابة، والطوبولوجيا الداخلية المستنبطة. يمكن للمشغّل البشري بعد ذلك توجيه الخطوات التالية، على سبيل المثال مطالبة النظام بالتوجه تحديدًا نحو مسارات البيانات الوصفية السحابية أو التحقق مما إذا كانت أي رموز تم إرجاعها صالحة مقابل واجهات برمجة التطبيقات الإدارية.

هذا النوع من سير العمل يحقق أمرين. إنه يجلب منصات الذكاء الاصطناعي إلى نفس حلقة الأمان القائمة على الأدلة التي تتمتع بها تطبيقات الويب وواجهات برمجة التطبيقات بالفعل، ويستفيد من نفس قدرات LLM التي سيستخدمها المهاجمون حتماً، ولكن في خدمة المدافعين. عندئذٍ لا يعود الخطأ الذي أصاب ChatGPT مفاجأة لمرة واحدة؛ بل يصبح حالة اختبار في مجموعة اختبار الانحدار التي يمكنك تشغيلها كلما أدخلت تكاملاً جديداً أو غيرت البنية التحتية للإجراءات الخاصة بك.

دروس عملية للفرق التي تقوم بالبناء على منصات الذكاء الاصطناعي

إذا كنت مهندس أمن أو مهندس معماري يستهلك خدمات الذكاء الاصطناعي بدلاً من بنائها، فإن هذه الحادثة لا تزال وثيقة الصلة بالموضوع. حتى لو لم تلمس GPTs المخصصة داخليًا أبدًا، فمن المحتمل أنك تعرض واجهات برمجة التطبيقات الداخلية أو لوحات المعلومات أو مخازن المستندات لوكلاء الذكاء الاصطناعي أو الطيارين المساعدين من نوع ما. الأفكار قابلة للنقل.

الخطوة الأولى هي التوقف عن التعامل مع LLM على أنه الشيء الوحيد الذي يحتاج إلى مراجعة أمنية. يجب النظر إلى أي ميزة تتيح للنماذج الاتصال ببيئتك - سواء من خلال أدوات صريحة أو إجراءات أو خطافات ويب غير مباشرة - على أنها رسم بياني محتمل للهجوم. يجب أن تكون قادرًا على الإجابة، بقدر من الثقة، عن الخدمات الداخلية التي يمكن لمكون الذكاء الاصطناعي التحدث إليها، والهويات التي يستخدمها، وما الذي يحدث إذا حاول مستخدم معادٍ توسيع تلك القدرات عمدًا.

الخطوة الثانية هي توسيع نطاق برامج الاختبار الخاصة بك لتغطية التعليمات البرمجية للذكاء الاصطناعي. عند تكليفك بإجراء اختبار اختراق أو إجراء تمرين داخلي للفريق الأحمر، تأكد من أن النطاق يشمل صراحةً عمليات تكامل الذكاء الاصطناعي: أسطح التكوين للأدوات، وطريقة إنشاء عناوين URL والعناوين، ومسارات الشبكة بين أوقات تشغيل الذكاء الاصطناعي والخدمات الحساسة، والحماية حول نقاط نهاية البيانات الوصفية. اطلب دليلاً على أن شخصًا ما، في مكان ما، حاول إساءة استخدام هذه الأمور كما يفعل المهاجمون الحقيقيون.

الخطوة الثالثة هي قبول أن سطح الهجوم هذا لن يتقلص. فمع توصيل المزيد من العمليات التجارية إلى الآليات طويلة المدى، سيكون هناك المزيد من الإجراءات والمزيد من المكونات الإضافية والمزيد من الخدمات الخلفية التي تؤدي العمل نيابةً عن المطالبات. يمكنك إما أن تقوم بتثبيت الأمان كسلسلة من التصحيحات المدفوعة بالحوادث، أو يمكنك بناء برنامج قابل للتكرار: نماذج تهديد واضحة، وأنماط بنية أساسية، وتدفقات اختبار مؤتمتة، وأدوات - من المحتمل أن تكون مدعومة بأنظمة مثل Penligent - التي تستمر في السبر مع تطور بيئتك.

ما وراء العنوان

من السهل أن يساء قراءة اختراق GPT SSRF المخصص لـ GPT SSRF على أنه إحراج لمرة واحدة لبائع واحد. من الأفضل قراءته على أنه معاينة. تنمو منصات الذكاء الاصطناعي بسرعة لتصبح طبقات تنسيق تربط المستخدمين والنماذج وواجهات برمجة التطبيقات والبنية التحتية السحابية. ويأتي هذا الدور مع القوة، ودائماً ما تأتي القوة مصحوبة بنصف قطر انفجار أكبر عندما يحدث خطأ ما.

الجزء المشجع في هذه القصة هو أنها تُظهر أيضًا الطريق إلى الأمام. تم العثور على الثغرة من قبل باحث اتبع غرائز قديمة في سياق جديد. تم الإبلاغ عن الثغرة من خلال قناة مكافأة الأخطاء القياسية. تم إصلاحها. يمكن لبقيتنا الآن اتباع نفس قواعد اللعبة وتطبيقها بشكل استباقي على أنظمتنا الخاصة، ومن الناحية المثالية بمساعدة الأدوات التي تفهم كلاً من الأمن والذكاء الاصطناعي.

إذا فعلنا ذلك، فإن إرث هذا الحادث لن يكون مجرد "كان لدى ChatGPT ذات مرة SSRF". بل يصبح دراسة حالة في كيفية التفكير في أمن الذكاء الاصطناعي: تعامل مع النماذج كمكون واحد في نظام أكبر، وتعامل مع عمليات التكامل كسطوح هجوم خطيرة، واستخدم الأتمتة بالإضافة إلى البصيرة البشرية - سواء من خلال منصات مثل Penligent أو خطوط الأنابيب الداخلية الخاصة بك - لتحويل القلق الغامض باستمرار إلى ضمان ملموس وقابل للاختبار ومدعوم بالأدلة. هذا هو نوع القصة التي تستحق أن تُروى على Medium، بل وتستحق أن تعيشها داخل مؤسستك الهندسية.