حقن الأوامر في روبوتات الدردشة الفارسية

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

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

حقن الأوامر في فقرتين

يتلقّى النموذج اللغوي تعليمات النظام ورسالة المستخدم والمستندات المُسترجَعة ومُخرَج الأدوات بوصفها تدفّقاً واحداً من النص. وليست لديه طريقةٌ موثوقة لمعرفة أيّ جزءٍ تعليمةٌ وأيّ جزءٍ يبدو كتعليمةٍ لا أكثر. وكلّ من يستطيع وضع نصٍّ أمام النموذج يمكنه أن يحاول توجيهه.

إذن «المستخدم» ليس الوحيد الذي ينبغي القلق بشأنه. فكاتب أيّ صفحة ويب يقرؤها التطبيق، وأيّ ملفّ PDF مرفوع، وأيّ تذكرة، وأيّ بريد إلكتروني، كلّها تستطيع إدخال نص. وتُسمّى الحالة الثانية حقناً غير مباشر، وهي عملياً الأخطر، لأنّ الضحية لا يفعل شيئاً مريباً إطلاقاً. وقد تناولنا المنهج العامّ لاختبار هذه التطبيقات في كيف تُجري اختباراً أمنياً لتطبيق LLM؛ وهذه المقالة عن طبقةٍ واحدة منه: النصّ نفسه.

لماذا تُغيّر الفارسية الصورة

تبحث المرشّحات إمّا عن سلاسل نصّية وإمّا تُصنّف المُدخَل بنموذجٍ أصغر. وكلا الأسلوبين يفترض أنّ النصّ يصل تقريباً بالشكل الذي كان عليه حين كُتِب المرشّح. والفارسية تكسر هذا الافتراض بطرقٍ عدّة، ولا يُغيّر أيٌّ منها معنى الجملة بالنسبة إلى النموذج.

حرفٌ واحد، رمزان. فالحرف الفارسي «ی» والحرف العربي «ي» محرفان مختلفان يتشابهان في معظم الخطوط. وكذلك «ک» و«ك». وقائمة حظرٍ مكتوبةٌ بأحد الشكلين لا ترى الآخر.

مسافاتٌ لا تُرى. فالفاصل عديم العرض (zero-width non-joiner) محرفٌ حقيقي في الفارسية: إن أزلتموه صار النصّ عسير القراءة، فلا يستطيع أيّ تطبيقٍ أن يحذفه ببساطة. وإلى جانبه محارف أخرى عديمة العرض لا تُرى إطلاقاً. والكلمة التي يتوسّطها أحدها هي الكلمة نفسها للقارئ، وكلمةٌ أخرى لمطابقة السلاسل النصّية.

ثلاث مجموعات من الأرقام. فالأرقام الفارسية والأرقام العربية الهندية والأرقام اللاتينية تظهر جميعها في النصّ الفارسي. وقاعدةٌ مكتوبةٌ لمجموعةٍ واحدة تُفلِت البقية.

الـFinglish. كتابة الفارسية بالحروف اللاتينية أمرٌ شائع في إيران، والنماذج الكبيرة تقرؤها دون عناء. أمّا بالنسبة إلى مرشّحٍ يحمل قائمة كلماتٍ فارسية، فذلك النصّ ليس فارسياً إطلاقاً.

محارف التوجيه. في Unicode محارف تُغيّر اتجاه عرض النص. وبها يمكن ألّا يكون ما يقرؤه موظّف الدعم في لوحة الإدارة هو السلسلة نفسها التي يتلقّاها النموذج. وهذه هي العائلة التي عُرِفت باسم Trojan Source في الكود المصدري، وهي تعمل في النصّ العادي بالقدر نفسه.

كلمتان تبدوان متطابقتين على الشاشة هما سلسلتان مختلفتان في نظر المُرشِّح:

denylist = ["کیک"]            # U+06A9 U+06CC U+06A9: Persian kaf, Persian yeh
text     = "كيك"              # U+0643 U+064A U+0643: Arabic kaf, Arabic yeh
text in denylist              # False: the same on screen, different code points
normalise(text) in denylist   # True, once Arabic letters are mapped to Persian

الصيغ الجديرة بالاختبار

يصف الجدول صيغاً، لا payloads جاهزة. والمقصود أن يتمكّن الفريق من بناء مجموعته الخاصة.

كلّ صفٍّ متغيّرٌ واحد. ولا قيمة للاختبار إلّا إذا غيّرتم متغيّراً واحداً في كلّ مرّة؛ وإلّا تعذّر عليكم معرفة أيّ تغييرٍ هو الذي نجح.

اختبار روبوت دردشة، خطوةً بخطوة

١. افهرِسوا الطرق التي يدخل بها النص. رسالة المستخدم واحدةٌ منها. واسم الملفّ المرفوع، ومتن المستند المُسترجَع، وعنوان التذكرة، واستجابة واجهة API من طرفٍ ثالث، بل وحتى رسالة خطأٍ من نظامٍ آخر، كلّها نصّ. وما يغيب عن هذه القائمة لا يُختبَر.

٢. ثبّتوا خطّ أساس. أرسِلوا أبسط صيغةٍ للتعليمة، بالفارسية الصريحة، دون أيّ تمويه. فإن نجحت، فقد انتهيتم وما بقي غير ضروري. وإن لم تنجح، عرفتم الآن ما الذي يلتقطه المرشّح.

٣. غيّروا متغيّراً واحداً. أعيدوا كتابة الجملة نفسها بإحدى الصيغ الواردة في الجدول. سجّلوا النتيجة. ثم عودوا إلى الأصل وجرّبوا التالية.

٤. اسلكوا المسار غير المباشر. ضَعوا النصّ في مستندٍ يسترجعه التطبيق بدل رسالةٍ ترسلونها بأنفسكم. فكثيرٌ من التطبيقات تتعامل مع مُدخَل المستخدم بحذر، وتفترض أنّ المحتوى المُسترجَع آمن.

٥. اسألوا عمّا يستطيع النموذج فعله، لا عمّا يقوله. فأن يقول النموذج ما لا ينبغي شيء، وأن يستدعي أداةً أو يُغيّر سجلّاً أو يُرسِل بياناتٍ إلى الخارج شيءٌ آخر. وخطورة النتيجة تأتي من وصول النموذج، لا من نبرة ردّه.

٦. كرّروا، وعُدّوا. سلوك النموذج احتمالي. فنجاحٌ واحد لا يُثبت أنّ المشكلة قائمةٌ دائماً، وفشلٌ واحد لا يُثبت غيابها. نفّذوا كلّ اختبارٍ عدّة مرّات، وبلّغوا عن النتيجة بوصفها معدّلاً: ثلاث مرّاتٍ من عشر.

٧. اقرؤوا السجلّات. فإن تعذّر العثور على النصّ المحقون في السجلّات، أو جرى تنظيفه إلى حدٍّ اختفى معه شكله الأصلي، لم يستطع فريق الأمن إعادة بناء هجومٍ وقع بعد حدوثه. وهذه نتيجةٌ بحدّ ذاتها.

سجلٌّ يحتفظ بالصيغتين معاً هو ما يجعل الهجوم مرئياً بعد وقوعه:

2026-09-21T10:14:03Z chat msg=48213 source=ticket.subject
  raw        = "\u0643\u064A\u0643 …"
  normalised = "کیک …"
  filter     = pass    tool_calls = 0

نموذج لنتيجة اختبار

الدفاع: التطبيع أولاً، ثم الترشيح

تُسلِّم معظم الفرق المرشّحَ نصّاً بالشكل نفسه الذي أرسله المستخدم. والترتيب الصحيح هو العكس.

طبِّعوا النصّ مرّةً واحدة، قبل اتّخاذ أيّ قرار: اربطوا المحارف العربية بمقابلاتها الفارسية، واحذفوا المحارف عديمة العرض ومحارف التوجيه أو أظهِروها، ووحِّدوا الأرقام، وطبّقوا صيغة تطبيعٍ واحدة من Unicode. ثم شغّلوا المرشّح والمصنّف على ذلك النصّ المُطبَّع. واحتفظوا بالأصل للعرض، حتى لا يضيع شيءٌ ممّا كتبه الشخص فعلاً.

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

ملاحظة: لا تحذفوا محرف عدم الوصل (ZWNJ)؛ فهو جزءٌ من الإملاء الفارسي الصحيح. احذفوا فقط المحارف غير المرئية التي لا وظيفة لها في النص، وأظهِروا البقية للمراجِع بدل حذفها.

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

ضوابط لا تعتمد على النموذج

أيّ دفاعٍ يعتمد على سلوك النموذج الصحيح قد يسلك سلوكاً مختلفاً يوم يُحدَّث النموذج. والضوابط الدائمة تقع خارجه:

• أقلّ امتيازٍ للأدوات. لا يصل النموذج إلّا إلى ما تتطلّبه مهمّته، عبر قائمة سماحٍ لا ثقةٍ عامّة.
• موافقةٌ بشرية على أيّ أمرٍ لا رجعة فيه. فالحذف والدفع وإرسال البيانات خارج المؤسسة لا ينبغي أن ينشأ عن جملةٍ في تذكرة.
• مُخرَج النموذج مُدخَلٌ غير موثوق. فحيثما يصل المُخرَج إلى متصفّحٍ أو استعلامٍ أو أمر، تعاملوا معه كما تتعاملون مع مُدخَلٍ من مستخدم.
• فصل مستويات الثقة في الاسترجاع. فالمستند الذي رفعه عميلٌ ليس كالمستند الداخلي المُعتمَد، وينبغي للتطبيق أن يعرف الفرق.
• سقوفٌ ومراقبة. حدودٌ للمعدّل على استدعاءات الأدوات، وتنبيهٌ حين يخرج نمط الاستخدام عن شكله المعتاد.

أسئلة تطرحونها على فريقكم أو على المورّد

أسئلة شائعة

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

هل النموذج الذي يفهم الفارسية فهماً أفضل أكثر أماناً كذلك؟ ليس بالضرورة. ففهم اللغة فهماً أفضل يعني فهم التعليمة المموَّهة فهماً أفضل أيضاً. والسؤال المهمّ في موضعٍ آخر: كم يثق التطبيق في المُخرَج، وإلامَ يصل النموذج.

كيف يختلف الحقن غير المباشر في التقرير؟ في الحالة المباشرة يتعيّن على المهاجم أن يُخاطب التطبيق. وفي الحالة غير المباشرة يكفي أن يترك نصّاً في مكانٍ يقرؤه التطبيق لاحقاً، والضحية لا يفعل شيئاً غير معتاد. والثانية تحمل عادةً الخطورة الأعلى.

كيف نُبلِّغ عن هجومٍ لا ينجح دائماً؟ بوصفه معدّلاً. سجّلوا عدد المحاولات وعدد مرّات النجاح، مع إصدار النموذج وتاريخ الاختبار، لأنّ كليهما يتغيّر مع أيّ تحديث.

هل يُفسِد التطبيعُ نصَّ المستخدم؟ لا، ما دامت النسخة المُطبَّعة تُستخدَم للقرارات فقط، والأصل يُحتفَظ به للعرض والتخزين.

إن كنتم تُشغّلون روبوت دردشة، أو مساعداً داخلياً، أو وكيلاً يقرأ نصّاً من الخارج، فاملؤوا قائمة نقاط الدخول تلك مرّةً واحدة مع فريقكم. ففيها عادةً مسارٌ واحد لم يخطر ببال أحد.