المتصفح كباب خلفي: إزالة الغموض عن الاستخراج السري من جانب العميل LLM

المتصفح باعتباره بابًا خلفيًا: إزالة الغموض عن عملية الاستخراج السري من جانب العميل في ماجستير إدارة الأعمال (LLM).

لقد تعاملنا لفترة طويلة جدًا مع "التحذيرات الأمنية للذكاء الاصطناعي" باعتبارها تهديدات بعيدة أو فضولًا أكاديميًا. لقد سمعنا عن الحقن الفوري، وكسر الحماية، وتسريب البيانات بنغمات خافتة، وغالبًا ما يتبعها هز الكتفين وقول "سوف نصل إلى الهدف". ومع ذلك، فقد حطمت المظاهرات التفاعلية الأخيرة هذا الوهم المريح. هذه ليست ثغرة أمنية نظرية بعد الآن؛ إنه استغلال مباشر قائم على المتصفح من جانب العميل لاستخراج المعلومات الحساسة من نماذج اللغات الكبيرة (LLMs) [2]. إذا كنت تقوم بنشر تطبيقات مدعومة بـ LLM، وخاصة أي شيء يتعلق بالويب، فإن "مشكلتك المستقبلية" أصبحت مسؤولية حاضرة جدًا وعامة جدًا وربما محرجة للغاية.

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

وهم الأمن النموذجي

لقد استثمرت العديد من المؤسسات بكثافة في برامج LLM "الآمنة"، إما من خلال ضبط نماذج الملكية أو الاعتماد على واجهات برمجة التطبيقات على مستوى المؤسسات مع حواجز حماية مفترضة. والافتراض الضمني هو أنه إذا كان النموذج نفسه قويًا، فإن التطبيق المبني فوقه سيرث هذا الأمان. وتكشف المظاهرات الأخيرة هذا الأمر باعتباره مفهوماً خاطئاً وخطيراً. الثغرة الأمنية ليست في الذكاء الأساسي للنموذج أو في بيانات التدريب الخاصة به؛ إنه موجود في الواجهة التي نبنيها حولها [1]. إنها مشكلة "القبو القوي والباب الأمامي الهش" الكلاسيكية. قد يكون لديك ماجستير إدارة الأعمال (LLM) الأكثر تقدمًا وصلابة في العالم، ولكن إذا كان محلل إدخال التطبيق الخاص بك ساذجًا، أو كان مرشح الإخراج الخاص بك غير موجود، فأنت في الأساس تترك المعلومات المهمة مكشوفة ليتمكن أي شخص من العثور عليها.

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

متصفحك، سلاحهم

حقيقة أن هذا الاستغلال يعتمد على المتصفح يغير اللعبة بالكامل. يعني:

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

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

المسؤولية تقع على عاتقك

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

إذن ماذا تفعل الآن؟

الإجراءات المضادة الفورية:

1. تطهير الإدخال العدواني: يتجاوز هذا مجرد منع حقن SQL أو XSS. أنت بحاجة إلى التدقيق في كل حرف يدخل إلى LLM الخاص بك. ابحث عن الأنماط التي تشير إلى الحقن الفوري، أو تسلسل الأحرف غير المعتاد، أو محاولات الخروج عن تدفقات المحادثة المتوقعة [4]. لا يتعلق الأمر بمنع "الكلمات البذيئة"؛ يتعلق الأمر بتحديد المطالبات العدائية. بعيدًا عن التعبير العادي الأساسي والتحليل الإرشادي، قم بتنفيذ التحليل الدلالي لاكتشاف النوايا الضارة. استخدم تحليل الترميز والتضمين لتحديد أنماط الإدخال الشاذة. فكر في استخدام ماجستير ثانوي أصغر أو نظام قائم على القواعد تم تدريبه خصيصًا لاكتشاف محاولات الحقن السريع. ابحث عن أنماط مثل تعليمات لعب الأدوار، أو طلبات استخراج البيانات الصريحة، أو محاولات تجاوز التعليمات السابقة.
2. ** تصفية قوية للمخرجات والتحقق من صحتها: ** لا تثق أبدًا في مخرجات LLM ضمنيًا. قبل أن يتم عرض أي نص تم إنشاؤه بواسطة LLM للمستخدم أو استخدامه بواسطة نظام آخر، يجب أن يمر عبر طبقة تحقق صارمة. هل تحتوي على كلمات رئيسية حساسة؟ هل يتوافق مع التنسيقات المتوقعة؟ هل يحاول تنفيذ التعليمات البرمجية أو الكشف عن مطالبات النظام الداخلي؟ إذا كان من المفترض أن يقوم برنامج LLM الخاص بك بتلخيص مستند، ولكنه يبدأ في سرد ​​مسارات الملفات، فهذا يعني أن لديك مشكلة.
3. هندسة المطالبة ذات الطبقات: على الرغم من أنها لا تمثل حلاً كاملاً، إلا أن مطالبات النظام المصممة جيدًا والأمثلة القليلة يمكن أن تساعد في تعزيز السلوك المرغوب وتجعل من الصعب على المهاجم اختطاف النموذج. ومع ذلك، افهم أن الهندسة السريعة وحدها غير كافية؛ إنه دفاع في العمق، وليس درعًا أساسيًا.
4. أقل امتياز لتفاعلات LLM: هل تحتاج شهادة LLM حقًا إلى الوصول إلى كل جزء من البيانات التي قد يُطلب منها الكشف عنها؟ تنفيذ ضوابط الوصول الصارمة. إذا كان من المفترض أن يجيب LLM فقط على الأسئلة المتعلقة بالوثائق العامة، فتأكد من عدم توفر وصول برمجي إلى قواعد البيانات الداخلية أو واجهات برمجة التطبيقات الحساسة.
5. ** المراقبة والكشف عن الحالات الشاذة: ** يجب أن تبحث بنشاط عن سلوك LLM غير المعتاد. يجب أن يؤدي الارتفاع المفاجئ في أنواع محددة من الاستعلامات، أو المخرجات التي تنحرف عن الأنماط العادية، أو المحاولات المتكررة لاستخراج المعلومات إلى إطلاق تنبيهات فورية.

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

المصادر

[1] أفضل 10 تطبيقات OWASP لنماذج اللغات الكبيرة — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [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