BrowseSafe++: بناء دفاعات أقوى ضد حقن الأوامر في العالم الحقيقي

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

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

بدافع من هذه التغيرات، أنشأنا معيارًا مرجعيًا محدّثًا، BrowseSafe++، لقياس ما إذا كانت أدوات اكتشاف الحقن الحالية ترصد هذه الهجمات، وما إذا كان الوكلاء قادرين على مقاومتها. ويضم المعيار 38,675 زوجًا من الصفحات المهاجَمة والنظيفة، بُني معظمها حول عمليات حقن جُمعت من العالم الحقيقي. ولكل صفحة، نعيد صياغة المحتوى المحيط لحماية الخصوصية مع الإبقاء على الهجوم حرفيًا. وتتوفر كل صفحة بالتنسيقات الأربعة التي يقرأها وكلاء المتصفح: HTML وMarkdown وأشجار إمكانية الوصول ولقطات الشاشة. واستخدمنا مجموعة فرعية من المعيار المرجعي لتدريب BrowseSafe-Guard، وهو زوج من الكواشف بحجم 0.8 مليار معامل: كاشف نصي وكاشف متعدد الوسائط. ويرصد كاشفا Guard عمليات الحقن بدقة أعلى من النماذج الموجَّهة بالمطالبات التي اختبرناها، بما فيها النماذج الرائدة. كما أنهما أسرع وأقل تكلفة، ويُعلّمان عن طريق الخطأ عددًا أقل بكثير من الصفحات العادية.

نطرح BrowseSafe++ معيارًا مرجعيًا مفتوحًا. ويتضمن الموقع الإلكتروني للمشروع روابط إلى مجموعة البيانات و SDK و الورقة البحثية و لوحة صدارة عامة. ويمكن لأي فريق تقييم الكاشف الخاص به على صفحات اختبار لم تُقدَّم تسمياتها، ثم إرسال التسميات لتقييمها وإمكانية إدراجها في لوحة الصدارة. لتقييم نتائجك وإرسالها، راجع البدء.

إنشاء معيار مرجعي من عمليات الحقن المرصودة

بُني BrowseSafe++ من عمليات حقن المطالبات التي رُصدت على مواقع إلكترونية حقيقية. فبين سبتمبر 2025 وسبتمبر 2026، علّمت أداة اكتشاف حقن المطالبات في Comet ‏1.15 مليون عملية حقن على صفحات قرأها وكيله. وأنشأنا 32,187 زوجًا حول عمليات الحقن تلك، وأضفنا 6,488 زوجًا من معيار BrowseSafe المرجعي الأصلي، ليصبح الإجمالي 38,675 زوجًا. ويضم كل زوج صفحةً مهاجَمة ونظيرتها النظيفة، وهي الصفحة نفسها دون الحقن.

كيف تبدو عمليات الحقن في الواقع

يوضح مثالان من المعيار المرجعي كيف تبدو عمليات الحقن هذه على أرض الواقع.

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

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

وفي مثال آخر، تهدف محادثة مزيّفة إلى تعطيل مهمة الوكيل. وقد عُثر على هذا النص في صفحة مستودع تعليمات برمجية في مارس 2026:

صُمّم النص ليبدو كمحادثة بين مستخدم ووكيل: <|im_start|> و<|im_end|> علامتان تستخدمهما بعض نماذج الدردشة للفصل بين أدوار المحادثة. والوكيل الذي يقع في فخ هذا الهجوم سيستجيب لاستعلام المستخدم المزيّف ويرد بعبارة المهاجم.

نلاحظ أنماطًا متشابهة عبر عمليات الحقن المُعلَّمة:

• إنها تحاكي مصادر موثوقة. يجعل كلا المثالين نص الصفحة يبدو صادرًا عن مصدر يثق به الوكيل: مطوّره في المثال الأول، ومحادثته الخاصة في الثاني. ويمكن لعمليات الحقن أيضًا أن تنتحل صفة الموقع نفسه، فتحاكي عمليات التحقق الأمنية وإشعارات السياسات، أو صفة المستخدم، فتطرح تفضيلات مزيفة. ونحو اثنتين من كل ثلاث منها مكتوبة بلغة رسمية.
• كثير منها مكتوب بلغات مختلفة. في 24.4% من الأزواج، يستخدم الحقن لغة مختلفة عن بقية صفحته. ويأخذ ذلك عادةً شكل تعليمات باللغة الإنجليزية على صفحة غير إنجليزية، كما في المثال الأول. ومن الواضح أن هذه الهجمات موجهة إلى وكيل يقرأ كل اللغات، وغالبًا ما تكون الإنجليزية لغته الأم. كما أن تبديل اللغة يجعل الاكتشاف أصعب: ففي تقييم BrowseSafe الأصلي الذي أجريناه، كانت الهجمات متعددة اللغات من بين الأصعب رصدًا.
• معظمها يريد أفعالًا لا أقوالًا. أكثر من أربعة من كل عشرة تدفع الوكيل نحو إجراء لم يطلبه المستخدم قط، مثل شراء الرمز المميّز في المثال الأول، ونحو الثلث يحاول دفعه إلى التخلي عن مهمة المستخدم، كما في المثال الثاني. ولا يحاول سوى نحو 3% منها زرع معلومات خاطئة في الإجابة.
• غالبًا ما تستغل محتوى يمكن لأي شخص نشره. لا يحتاج المهاجم إلى السيطرة على موقع ما. فمنشور في منتدى أو مستند مشترك على مواقع عادية يكفي، وقد وصلت أكثر من 23,000 عملية حقن في BrowseSafe++ بهذه الطريقة. ولا يزال من الممكن استغلال نطاق موثوق لحقن نص المهاجم.

تغطي عمليات الحقن الموجودة في المعيار المرجعي النهائي 12 نوعًا من المواقع الإلكترونية، و24 نوعًا من الهجمات، و6 أهداف للمهاجمين، و18 موضعًا على الصفحة.

تكبير

من صفحة مُعلَّمة إلى زوج في معيار التقييم

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

1. تحديد مصدر الحقن: نجمع الصفحات المُعلَّمة، ونزيل التكرارات، ونُخفي المعلومات الشخصية باستخدام PII-Tracer. بعد ذلك، نتأكد من أن الصفحة تحتوي على حقن؛ وتحديدًا، نشترط أن تتفق مجموعة من النماذج على أنها تحتوي على تعليمات تحاول صرف الوكيل عن المهمة التي يقصدها المستخدم.
2. إنشاء الزوج: يزيل وكيلٌ نص الحقن من كل صفحة ويعيد صياغة محتوى الصفحة المحيط، مستبدلًا تفاصيل مثل الأسماء والعلامات التجارية بأخرى خيالية. ويتحقق وكيل ثانٍ من الصفحة المعاد صياغتها بحثًا عن أي محتوى متبقٍ من العالم الحقيقي، ويعيد الحالات الفاشلة مع ملاحظات. ويفحص مراجعون بشريون عينة عشوائية تبلغ 10% من الصفحات؛ وتُصلَح المشكلات التي يجدونها في مسار المعالجة، وتُطبَّق الإصلاحات على مجموعة البيانات كاملة. ثم يُعاد إدراج الحقن في الصفحة المعاد صياغتها لإنشاء النسخة المهاجَمة، ويُستبعد من النسخة النظيفة. وتتشارك الصفحتان المهمة نفسها والنتيجة المتوقعة نفسها والتعليمات العادية نفسها.
3. التحقق: يقرأ الوكلاء الصفحات بأشكال مختلفة، لذا نحوّل HTML لكل صفحة إلى Markdown، وشجرة إمكانية الوصول (قائمة منظمة لعناصر واجهة الصفحة وتسمياتها)، ولقطة شاشة. ويتحقق وكيل آخر من ظهور الحقن في طرق العرض الأربع جميعها للصفحة المهاجَمة، ومن أن الصفحة النظيفة تُعدّ غير ضارة في كل طريقة عرض. وإذا كان الحقن مفقودًا في إحدى طرق العرض، ننقله إلى موضع مختلف في الصفحة ونعيد التحويل، بما يضمن ظهور الحقن في الصفحة المهاجَمة النهائية في جميع طرق العرض. وتصحح مجموعة نهائية من الفحوصات الآلية أي أزواج لا تزال تحمل آثارًا من مصدرها، مثل أسماء المضيفين الحقيقية أو أسماء العلامات التجارية.

تكبير

BrowseSafe-Guard: كواشف سريعة ودقيقة لكل طريقة عرض

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

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

يتكوّن Guard من أداتَي كشف، ضُبطت كلٌّ منهما بدقة انطلاقًا من Qwen3.5-0.8B. تقرأ أداة الكشف النصية تمثيلًا نصيًا واحدًا للصفحة: إما HTML أو Markdown أو شجرة إمكانية الوصول. أما أداة الكشف متعددة الوسائط فتقرأ لقطة شاشة للصفحة كاملة. وعند النشر، يقرأ Guard الصفحة في تمريرة أمامية واحدة ويُخرج درجة حقن، وتُعلَّم الصفحة إذا تجاوزت الدرجة عتبة محددة. ولأن Guard لا يحتوي إلا على 0.8 مليار معلمة ويُخرج درجة واحدة، فهو سريع ومنخفض التكلفة بما يكفي لتشغيله على كل صفحة.

قياس الأداء

قارنّا Guard مع 18 نموذجًا جرى توجيهها بالمطالبات لاكتشاف عمليات الحقن على مجموعة فرعية محجوزة من المعيار المرجعي. ونعرض أربعة مقاييس، مقيسة على BrowseSafe++:

• الاستدعاء (Recall) هو نسبة الصفحات المحقونة التي يُعلّمها الكاشف، وهو يقيس عدد الهجمات التي يرصدها، لذا فالأعلى أفضل.
• معدل الإيجابيات الكاذبة (FPR) هو نسبة الصفحات النظيفة التي يُعلّمها الكاشف عن طريق الخطأ، وهو يقيس عدد المرات التي يطلق فيها إنذارات كاذبة، لذا فالأقل أفضل.
• الدقة (Precision) هي نسبة الصفحات المُعلَّمة التي تحتوي فعلًا على حقن، وهي تقيس عدد المرات التي يكون فيها التنبيه صحيحًا، لذا فالأعلى أفضل.
• F1 هو المتوسط التوافقي للاستدعاء والدقة؛ ولا يكون مرتفعًا إلا عندما يرصد الكاشف معظم الهجمات، ويكون عدد قليل فقط من علاماته إنذارات كاذبة.

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

تكبير

تكبير

مقارنات النماذج

جاءت النماذج الصغيرة مفتوحة الأوزان التي اختبرناها في المراتب الأخيرة. إذ يُعلّم كلٌّ من Mistral NeMo وQwen3 30B-A3B نحو نصف الصفحات النظيفة، بينما نادرًا ما يُعلّم Llama 3.1 8B أي شيء، فيفوّت معظم الهجمات. وحتى أقوى نموذج في المجموعة، GPT-OSS 20B، لا يتجاوز F1 لديه 70.97%. أما DeepSeek V3.1، وهو نموذج مفتوح الأوزان أكبر بكثير، فأداؤه أفضل قليلًا، إذ يبلغ F1 لديه 75.23%.

تكتشف نماذج API الخفيفة، ومنها GPT-5.4 nano وGemini 3.1 Flash-Lite وClaude Haiku 4.5، مزيدًا من الهجمات، بمعدل استدعاء يتراوح بين 85% و97%. لكن الثمن نسبة مرتفعة من الإنذارات الكاذبة؛ إذ يسجّل Gemini 3.1 Flash-Lite أدنى معدل نتائج إيجابية خاطئة (FPR) في المجموعة بنسبة 35.2%، بينما يقارب معدل FPR لدى Haiku نسبة 69%. ونتيجة لذلك، تبلغ أعلى درجة F1 في المجموعة 80.9%، وقد حققها Gemini 3.1 Flash-Lite.

أما النماذج المتبقية فهي نماذج عامة أقوى، تتراوح درجات F1 لديها بين 85% و92%. ومع ذلك، لا تزال تواجه مفاضلات بين الاستدعاء ومعدل FPR؛ فالنماذج التي تميل إلى الحذر تحظر صفحات مشروعة، والنماذج التي تُعلّم الصفحات بوتيرة أقل تفوّت الهجمات. يتمتع Claude Sonnet 5 بأعلى استدعاء بين جميع الكواشف بنسبة 98.73%، لكن معدل FPR لديه يبلغ 24.65%. ويصل Gemini 3.1 Pro وGPT-5.5 إلى استدعاء بنسبة 97.78% و97.19%، مع معدلي FPR يبلغان 19.80% و20.44% على التوالي. ويتمتع GPT-6 Astra بأعلى دقة إجمالية، باستدعاء يبلغ 96.42% ومعدل FPR يبلغ 14.41%. ويأتي Decider في المرتبة الثانية، باستدعاء يبلغ 96.02% ومعدل FPR يبلغ 17.44%. ويسجّل Claude Opus 5.5 أدنى معدل FPR بنسبة 4.21% فقط، لكن استدعاءه البالغ 77.71% يعني أنه يفوّت أكثر من هجوم واحد من كل خمسة هجمات. ويبدو Claude Fable 5.1 قويًا على الصفحات التي يجيب عنها، باستدعاء يبلغ 89.31% ومعدل FPR يبلغ 7.92%، لكنه يرفض الإجابة على نحو 30% من الصفحات، وهي حالات يحتسبها الصف «(all)» علامات اكتشاف.

تكبير

يدفع Guard حدود باريتو إلى الأمام، محققًا توازنًا أفضل بين الهجمات الفائتة والإنذارات الكاذبة. إذ يبلغ F1 لديه نحو 95%، ويحتل المرتبة الأولى في كل طريقة عرض نصية. ولا يُعلّم سوى صفحة نظيفة واحدة تقريبًا من كل 20 صفحة، أي نحو ثلث معدل Astra، النموذج الموجَّه الأعلى دقة. ويعود هذا الفرق إلى التدريب الذي أجريناه؛ إذ إن نموذج Qwen3.5-0.8B الأصلي الذي بُني عليه Guard، عند توجيهه بالطريقة نفسها المستخدمة مع النماذج الأخرى، لا يتجاوز F1 لديه 64%، ويُعلّم نحو ثلاث من كل أربع صفحات نظيفة. وفي سيناريو العرض بلقطات الشاشة، نقارن الكاشف متعدد الوسائط في Guard بأربعة نماذج قادرة على معالجة الصور. وعند تزويده بلقطات شاشة للصفحة كاملة، يحقق Guard نحو 93% في F1، مقابل نحو 79% لأفضل النماذج الأخرى التي قيّمناها.

التعرف على الهجوم لا يعني مقاومته

من البديهي أن النموذج القادر على التعرف على الحقن بشكل صحيح ينبغي أن يتجاهل ذلك الحقن أيضًا عندما يصادف الصفحة أثناء إنجاز مهام المستخدم. ومع ذلك، تُظهر تجاربنا أن درجات الاكتشاف المرتفعة لا تضمن أن يقاوم النموذج الهجوم. فقد قدّمنا لكل نموذج الصفحة المهاجَمة نفسها مرتين: مرة للحكم على ما إذا كانت تحتوي على حقن، ومرة لتنفيذ مهمة المستخدم دون الاطلاع على الحكم السابق. وتحقّق مُقيِّم منفصل مما إذا كان النموذج قد اتّبع الحقن. وقد ظل كل نموذج خضع للاختبار يتّبع بعض عمليات الحقن التي سبق أن علّمها، بدءًا من 1.64% من الصفحات المُعلَّمة لدى GPT-6 Astra ووصولًا إلى 24.73% لدى Llama 3.1 8B.

تكبير

لا تتنبأ درجات الاكتشاف بشكل موثوق بالفروق بين النماذج. إذ يرصد Claude Sonnet 5 وGPT-5.5 عمليات الحقن بكفاءة متقاربة، بدرجتي F1 تبلغان نحو 88% و89% على التوالي. ومع ذلك، اتّبع Sonnet 5 حقنًا سبق أن علّمه في 19.74% من الصفحات، أي بمعدل يبلغ عشرة أضعاف معدل GPT-5.5 البالغ 1.97%.

نظام قابل للنشر للدفاع ضد هجمات الحقن

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

صُمّم Guard ليكون أداة الكشف تلك. فإلى جانب حصوله على أعلى درجة F1 وأعلى دقة بين جميع النماذج التي اختبرناها، فإن صغر حجمه يجعل تشغيله على كل صفحة منخفض التكلفة بما يكفي. وفي المتوسط، استهلك Guard نحو 0.15 ثانية من وقت GPU لكل صفحة نصية. وعلى وحدة H200 مستأجرة، نقدّر التكلفة بـ 0.18 دولار لكل 1,000 صفحة، مقارنةً بما يتراوح بين 18.95 و180.61 دولارًا لنماذج API الرائدة وفق أسعار القائمة. ويجعل ذلك الفحص المتكرر أقل تكلفة بكثير في مقارنتنا، مع الحفاظ على درجات كشف مرتفعة.

يوضح الشكل أدناه الدقة الإجمالية لكل كاشف مقابل الوقت الذي يستغرقه لكل صفحة وتكلفته لكل 1,000 صفحة، وكلاهما على مقياس لوغاريتمي. ينفرد Guard بالزاوية العلوية اليسرى في كلتا اللوحتين: فهو يتفوق في الدقة الإجمالية والسرعة والتكلفة. ويستغرق كل نموذج موجَّه بالمطالبات نحو ثانية أو أكثر لكل صفحة، كما تتجاوز تكلفة النموذجين الأعلى دقة، GPT-6 Astra وClaude Fable 5.1، مبلغ 100 دولار لكل 1,000 صفحة.

تكبير

اختبار الدفاعات ضد الهجمات التكيفية

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

1. إعداد الحالة. تجمع الحالة بين إدخال من BrowseSafe++ ووكيل مستهدف. ويتضمن إدخال BrowseSafe++ سيناريو يشمل استعلامًا ومهمة للمستخدم، وصفحة تعرضت للهجوم، والنتيجة التي يسعى إليها المهاجم. ويعمل الوكيل داخل Sandbox توفر الأدوات والبيانات الاصطناعية اللازمة لتنفيذ المهمة. ويقيّم نموذج تحقق منفصل ما إذا كان الهجوم قد حقق هدفه.
2. تشغيل محاولة: ندرج الحقن الحالي في الصفحة ونترك الوكيل ينفذ المهمة. ويتحقق المُدقِّق من إجابة الوكيل وأي تغييرات أجراها على بيئة Sandbox لتحديد ما إذا كان الهجوم قد نجح. وتستخدم المحاولة الأولى الحقن الوارد في إدخال BrowseSafe++ الأصلي.
3. المراجعة والتكرار: إذا فشل هجوم ما، نؤرشف المحاولة، ويراجع نموذج ناقد سبب الإخفاق. ويستخدم نموذج مهاجم تلك الملاحظات لإعادة صياغة الحقن؛ إذ يمكنه تغيير صياغة الهجوم أو تنسيقه أو موضعه على الصفحة. ويظل هدف الهجوم ومعايير النجاح ومحتوى الصفحة المحيط كما هي. وتستخدم المحاولة التالية الهجوم المحدَّث. وتتكرر هذه العملية حتى ينجح الهجوم أو يبلغ المهاجم حدًا محددًا للمحاولات.

تكبير

اختبرنا سبعة وكلاء، كلٌّ منهم مبني على نموذج مختلف: Claude Sonnet 5 وClaude Haiku 4.5 وGPT-5.5 وGemini 3.1 Pro وGemini 3.5 Flash-Lite، والنموذجان مفتوحا الأوزان DeepSeek V3.1 وKimi K2. واجه كل وكيل المهام نفسها البالغ عددها 1,024 مهمة، بحد أقصى 64 محاولة لكل مهمة. في المحاولة الأولى، كان معدل نجاح الهجمات منخفضًا لدى الوكلاء السبعة جميعًا؛ إذ لم تنجح عمليات الحقن الأصلية إلا في 4% على الأكثر من المهام المُقيَّمة ضد أي وكيل. أما في ظل الإطار التكيفي، فقد ارتفع معدل نجاح الهجمات ارتفاعًا كبيرًا، إذ نجح المهاجم في 79% على الأقل من المهام ضد خمسة من الوكلاء السبعة. وحتى أقوى الوكلاء كانوا عرضة للاختراق: فقد ظلت الهجمات تنجح في نحو مهمتين من كل ثلاث مهام ضد GPT-5.5، وفي نحو مهمة واحدة من كل ثلاث ضد Claude Sonnet 5.

يبلغ الفرق بين الوكلاء أقصاه عندما يكون هدف المهاجم دفع الوكيل إلى إجراء استدعاء أداة معيّن. ففي المهام ذات هذا النوع من الأهداف، رضخ Sonnet 5 في نحو 8% من المهام، وGPT-5.5 في نحو 29%. أما الوكلاء الخمسة الآخرون فقد نفّذوا هدف المهاجم في أكثر من نصف مهامهم.

شغّلنا أيضًا BrowseSafe-Adapt ضد وكيل Gemini 3.5 Flash-Lite مع قيام Guard بفحص كل صفحة أولًا. حظر Guard نسبة 94.5% من عمليات الحقن الأصلية، وضاعف تقريبًا متوسط عدد المحاولات التي احتاج إليها المهاجمون، من 9.7 إلى 17.0. ومع ذلك، عند إتاحة المحاولات الـ64 كلها، ظل المهاجم ينجح في 84.2% من المهام (93.6% من دون Guard)، وكان ذلك دائمًا تقريبًا بحقن لم يُعلّمه Guard. ويتوافق هذا مع الرؤية التي عرضناها عند إطلاق BrowseSafe: لا يوجد نموذج اكتشاف يمثّل حلًا سحريًا، لذا يجب أن يكون الكاشف جزءًا من دفاع متعدد الطبقات.

تكبير

الخلاصة

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

تتصدى مجموعة BrowseSafe لهذه التهديدات. إذ يضم معيار BrowseSafe++ المرجعي 38,675 زوجًا من صفحات الويب بُنيت أساسًا من عمليات حقن حقيقية، مما يتيح تدريبًا وتقييمًا أكثر موثوقية لأدوات الاكتشاف. وتتيح كواشف BrowseSafe-Guard، المدرّبة على هذه الأزواج، اكتشافًا عالي الدقة وسريعًا ومنخفض التكلفة، مما يجعل من الممكن فحص الصفحات قبل أن يتصرف الوكيل بناءً عليها. ويتيح إطار BrowseSafe-Adapt اختبار النماذج في مواجهة عمليات حقن معدّلة، مما يكشف عن ثغرات قد لا تظهر من محاولات منفردة تستخدم عمليات حقن ثابتة.

نأمل أن تسهّل هذه الأدوات مجتمعةً على الباحثين والمهندسين اكتشاف الإخفاقات وتحسين الدفاعات ضد هجمات حقن المطالبات عبر الويب. كما نعمل باستمرار على تقييم الدفاعات المدمجة في Comet وComputer وتحسينها للحفاظ على أمان مستخدمينا.

البدء

1. ثبّت حزمة SDK واحصل على إمكانية الوصول إلى البيانات. تُثبَّت حزمة SDK من GitHub:

الوصول إلى مجموعة البيانات مقيّد. اطلب الوصول مرة واحدة عبر صفحتها على Hugging Face، ثم سجّل الدخول باستخدام hf auth login.

2. أرسل نتائجك إلى لوحة الصدارة. قيّم الكاشف الخاص بك على قسم الاختبار في BrowseSafe++:

يكتب هذا قرارًا واحدًا لكل صفحة لكل تمثيل تُدرجه؛ أدرِج التمثيلات النصية الثلاثة جميعها للحصول على متوسط في لوحة المتصدرين النصية. سجّل الدخول إلى مساحة لوحة المتصدرين باستخدام حسابك على Hugging Face، ثم ارفع predictions.jsonl. تُرجع المساحة درجة F1 والدقة ومعدل النتائج الإيجابية الخاطئة وغيرها من المقاييس لكل تمثيل، وتنشر النتيجة على لوحة المتصدرين إذا اخترت ذلك. ويحصل كل حساب (لا يقل عمره عن 60 يومًا) على عملية إرسال واحدة مُقيَّمة في كل أسبوع بتوقيت UTC. صفحات الاختبار مخصصة للتقييم فقط: لا تستخدمها للتدريب ولا تُعِد توزيعها. ويشرح دليل الإرسال تنسيق الملف وقواعد النشر.

الاستشهاد

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}