الاختبار الهجومي لـ LLM مقابل اختبار اختراق تطبيقات الويب: ما يغطيه كل منهما وتكلفته ومتى تحتاجون إليهما معًا

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

ما الذي يغطيه اختبار اختراق تطبيقات الويب

اختبار اختراق تطبيق الويب هو محاولة مصرّح بها لاختراق تطبيقكم العامل، باستخدام أساليب الصندوق الأسود أو الرمادي أو الأبيض بحسب مقدار الوصول الممنوح للمختبِرين. وتتوافق التغطية المعتادة مع OWASP Top 10: التحكم في الوصول المعطّل، والحقن، وإخفاقات المصادقة، والإعدادات غير الآمنة، والمكونات المعرضة للثغرات، وما شابهها من المشكلات.

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

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

ما الذي يغطيه الفريق الأحمر لنماذج LLM

يتعامل الفريق الأحمر لنماذج LLM مع النموذج، وكل ما هو مرتبط به، بوصفه الهدف. وأنواع الهجمات الرئيسية هي:

• حقن الأوامر المباشر: يكتب المستخدم تعليمات تحاول تجاوز موجّه النظام لديكم ("تجاهل تعليماتك السابقة").
• حقن الأوامر غير المباشر: تعليمات خبيثة مخفية في صفحة ويب أو مستند أو بريد إلكتروني أو نتيجة أداة يقرؤها النموذج نيابةً عن المستخدم.
• كسر القيود (Jailbreaks): دفع النموذج إلى تجاوز حدود الأمان والسياسات المفروضة عليه.
• استخراج البيانات: جعل النموذج يكشف موجّهه أو بيانات مستخدمين آخرين أو محتوى تدرّب عليه أو يسترجعه.
• حجب الخدمة للنموذج: أوامر مصممة لاستهلاك قدر مفرط من القدرة الحاسوبية أو التكلفة.
• تسميم الاسترجاع: زرع محتوى في المستندات التي يبحث فيها نظام الاسترجاع لديكم (RAG) بحيث يكرره النموذج أو يتصرف بناءً عليه.
• إساءة استخدام الأدوات من قِبل الوكيل: إقناع وكيل بالاستعانة بأداة قوية، مثل إرسال البريد الإلكتروني أو إصدار المبالغ المستردة أو حذف السجلات، بمدخلات يتحكم بها المهاجم.
• تصعيد النطاق عبر خوادم MCP والإضافات: استخدام أداة متصلة للوصول إلى بيانات أو إجراءات لا ينبغي أن تكون متاحة للمستخدم.
• مخاطر سلسلة التوريد: موجّهات أو نماذج أو أدوات خبيثة من أطراف ثالثة.

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

أين يتداخل الاثنان

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

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

هل تحتاجون إلى أحدهما أم كليهما؟

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

عندما تكون الميزانية محدودة، ابدؤوا بسرد ثلاثة أمور: ما البيانات التي يستطيع النموذج رؤيتها، وما الإجراءات التي يستطيع اتخاذها، ومن يستطيع التحدث إليه. وكلما زاد كل منها، زادت إلحاحية الاختبار.

قلّلوا المخاطر قبل الاختبار

لا يمكن القضاء على حقن الأوامر تمامًا اليوم، لذلك يفترض التصميم الجيد أن النموذج سيُخدع أحيانًا ويحدّ من الضرر:

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

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

ما الذي يمكن توقعه من المهمة

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

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