01تحديد النطاق والحصر
تبدأ العملية بتحديد موضوع الفحص: النقل (stdio أو Streamable HTTP أو مسار HTTP+SSE الملغى)، ومراجعة البروتوكول، والأطراف الثلاثة: الخادم والعميل/المضيف والبوابة. فالمراجعة وحدها هي التي تحدد أيّ فئات الهجوم موجودة أصلًا – فاختطاف الجلسات عبر ترويسة Mcp-Session-Id مثلًا لم يعد موجودًا في المراجعة 2026-07-28، وفي المقابل تُضاف State-Handles والتحقق من تطابق الترويسة مع المتن (Header-Body). نحصر كل خادم وكل أداة مع تعريفها الكامل وكل بيانات اعتماد وكل نظام هدف يمكن الوصول إليه عبرها، ونحدد مسبقًا كتابيًا بأيّ هويات اختبار ونطاقات (Scopes) سنعمل، لأن tools/list قد يختلف بحسب التفويض المقدَّم. وتنتمي أدوات الفحص أيضًا إلى تحديد النطاق: فقد كان MCP Inspector – أداة الاختبار الرسمية للمشروع – نفسه موضوع ثغرة أمنية حرجة هي CVE-2025-49596، لم تُعالَج إلا في الإصدار 0.14.1؛ لذا يجب توثيق إصداره وإيراده في التقرير.
02الهوية والصلاحيات (MCP07، MCP02)
نفحص هنا وفق متطلبات معيارية لا وفق الذوق: يجب أن ينتهي استدعاء أداة دون رمز أو برمز غير صالح بالرمز 401 مع ترويسة WWW-Authenticate صحيحة، ويجب أن تكون سلسلة الاكتشاف (Discovery) موجودة ومربوطة بشكل صحيح. ويجب التمييز هنا: فبيانات Protected Resource Metadata وفق RFC 9728 إلزامية لخوادم MCP، أما لخادم التفويض فيكفي اختياريًا RFC 8414 أو OpenID Connect Discovery 1.0 – ومن يفحص وفق RFC 8414 فقط ينتج نتيجة خاطئة مع خوادم OIDC. وتتوقع المواصفة لعناوين OAuth استخدام HTTPS خارج عناوين Loopback. وحالة الاختبار المحورية هي فحص الجمهور (Audience)، لأن المواصفة تحظر صراحةً تمرير الرموز (Token-Passthrough) – فلا يجوز للخادم قبول رموز لم تُصدر له. وفي البنى القائمة على الوكيل (Proxy) يُضاف مسار Confused Deputy: صفحة موافقة مستقلة لكل عميل، ومقارنة نصية دقيقة لـ redirect_uri دون أحرف بدل (Wildcards)، ومعامل state مُولَّد تشفيريًا ويُستخدم مرة واحدة. ونفحص كذلك تقليل النطاقات: نطاقات Wildcard أو Omnibus، والصلاحيات المجمّعة، والخوادم التي تثق في ادعاء Scope داخل الرمز دون أن تجري التفويض بنفسها.
03تعريفات الأدوات: Poisoning وShadowing وRug Pull (MCP03)
أوصاف الأدوات وتوثيق المعاملات ومخططات JSON هي قناة تعليمات يقرؤها النموذج باعتبارها موثوقة، ولا يراها الإنسان في الواجهة كاملةً في العادة. ننشئ أولًا خط أساس: إذ يُحسب لكل تعريف من tools/list وresources/list وprompts/list تجزئة (Hash) لكل حقل على حدة، ويُستخدم كمرجع للمقارنات اللاحقة. تليها ثلاثة فحوص – مقارنة النص الظاهر في العميل بالوصف الفعلي المُمرَّر إلى النموذج، واختبار Rug Pull المضبوط في بيئة الاختبار (إذا تغيّر تعريف سبقت الموافقة عليه، يجب على المضيف طلب الموافقة مجددًا أو الإبلاغ عن التغيير)، واختبار Shadowing بخادمين متصلين بالتوازي يقدّمان أدوات بالاسم نفسه أو متداخلة وظيفيًا. وهذه الفئة مثبتة عمليًا: ففي CVE-2025-54136 في Cursor أصبحت التغييرات على إعدادات MCP سبقت الموافقة عليها سارية دون موافقة جديدة.
04حقن الموجّهات غير المباشر عبر مخرجات الأدوات (MCP06)
ليس الوصف وحده، بل جانب الإرجاع أيضًا سطح هجوم: إذ تُلزم المواصفة الخوادم صراحةً بتنقية مخرجات الأدوات (MUST)، وتوصي العملاء بالتحقق من نتائج الأدوات قبل تمريرها إلى النموذج (SHOULD) – ويجب أن تعكس صياغة النتيجة المتطلب الأضعف على جانب العميل. نحصر أولًا جميع القنوات التي يصل عبرها محتوى خارجي إلى السياق – ردود الأدوات، والصفحات والمستندات المسترجعة، ومحتويات المستودعات، والتذاكر، وصناديق البريد، والذاكرة المحفوظة – وندرج في كل قناة علامة غير ضارة يمكن تتبعها بوضوح، لملاحظة ما إذا كان الوكيل يعاملها كتعليمات أم كبيانات. ويُفحص في ذلك سؤال معماري جوهري: هل يوجد فصل في المصدر بين التعليمات والبيانات، أم ينتهي الاثنان في نافذة السياق نفسها؟ وإذا اجتمع لدى وكيل في آن واحد الوصول إلى بيانات حساسة ومعالجة محتوى غير موثوق وإمكانية التواصل الخارجي – أي Lethal Trifecta وفق Simon Willison –، فإن النتيجة تكون مبرَّرة معماريًا بالفعل، حتى دون عرض توضيحي ناجح منفرد.
05النقل والتنفيذ وسلسلة التوريد (MCP05، MCP04، MCP09)
تسري على النقل متطلبات صارمة: يجب على الخوادم التحقق من ترويسة Origin للاتصالات الواردة، وينبغي أن ترتبط النسخ العاملة محليًا بـ 127.0.0.1 بدلًا من 0.0.0.0 – وإلا تكفي زيارة صفحة ويب للتواصل مع خادم محلي عبر DNS-Rebinding. نفحص التحقق من جانب الخادم مقابل المخطط المُعلَن، والتعامل مع العناوين في مسار OAuth-Discovery (النطاقات الخاصة وLink-Local، وسلاسل إعادة التوجيه، وDNS-Rebinding كسيناريو TOCTOU)، إضافةً إلى العزل (Sandboxing) والتحكم في حركة الخروج (Egress) لتنفيذ الأدوات؛ فمجرد إثبات أن مُدخلًا يصل إلى مفسّر دون فحص يُعدّ نتيجة بحد ذاته. وعلى جانب سلسلة التوريد نطابق بين إدخال السجل (Registry) والمستودع والمشرف (Maintainer)، ونفحص تثبيت الإصدارات (Version-Pinning) والتواقيع وبوابات الموافقة على التحديثات – فتسميات مثل «official» أو «verified» ليست دليلًا على الثقة، كما أظهرت CVE-2025-6514 في الحزمة الواسعة الانتشار mcp-remote (الإصدارات المتأثرة من 0.0.5 حتى 0.1.15، والمعالجة في 0.1.16). ويُضاف إلى ذلك البحث عن الخوادم الخفية (Shadow Servers) عبر فحوص المستودعات ونقاط النهاية، وفحوص شبكية متكررة مع تقرير بالفروقات، والتحليل عند البوابة، لأن هناك يُقاس أيّ الخوادم يتصل بها الوكيل فعليًا – وليس فقط أيّها مذكور في الإعدادات.
06القياس عن بُعد وتوثيق الأدلة والتقرير (MCP08)
يأتي السؤال الأصعب في النهاية: هل يمكن لاحقًا إعادة بناء أيّ وكيل استدعى أيّ أداة وفي أيّ وقت وبأيّ معاملات ونيابةً عن أيّ هوية؟ لهذا الغرض ننفّذ سلسلة إجراءات محددة وغير ضارة – اتصال، وسرد الأدوات، وعدة استدعاءات، واستدعاء مرفوض – ثم نحاول إعادة بناء هذه السلسلة بالضبط من السجلات وحدها؛ والنتيجة السلبية الواضحة هنا نتيجة كاملة القيمة، لأنها تجعل جميع النتائج الأخرى غير قابلة للإثبات أثناء التشغيل. وفي التقرير نفصل بين فئتين من الأدلة: نتائج الإعدادات والبنية قابلة للإثبات بشكل حتمي، أما النتائج القائمة على السلوك فليست كذلك – ولها نذكر عدد التكرارات ونسبة النجاح إضافةً إلى النموذج والعميل والإصدار. كما يُنسب كل نتيجة إلى المستوى الذي تقع فيه (البروتوكول والنقل، التفويض، تعريف الأداة، العميل/المضيف، مستوى الوكيل)، لأن الإجراء المضاد والمسؤول يختلفان باختلاف المستوى.
