OWASP MCP Top 10: شرح كل خطر بالأمثلة

يمكن لخادم MCP واحد أن يمنح وكيل الذكاء الاصطناعي مستودعاتك وبريدك الوارد وقاعدة بياناتك في بعد ظهر واحد، وغالبًا ما تحتاج الموافقة عليه إلى نقرة واحدة. هذه السهولة بالضبط هي ما جاء OWASP MCP Top 10 ليواجهها. فهو يسمّي المخاطر العشرة الأكثر احتمالًا لإفشال أي نشر لبروتوكول Model Context Protocol، من التوكنات المسرّبة إلى خوادم لا يعرف فريق الأمن بوجودها. تمرّ هذه المقالة على كل بند بالترتيب، وتعرض شكل الهجوم بمثال حقيقي أو موثّق، وتختم كل قسم بالإصلاح الذي يستحق القيام به أولًا.

القائمة مأخوذة من مشروع OWASP MCP Top 10 الإصدار 2025، بقيادة Vandana Verma Sehgal. تشير صفحة المشروع حاليًا إلى أنه في مرحلة الاختبار التجريبي والتجريبي المحدود، لذا قد تتغير الصياغة والترتيب. تعامل مع البنود العشرة كمفردات مشتركة لا كمعيار نهائي.

ما هو OWASP MCP Top 10

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

يرسم Top 10 الأماكن التي تنكسر فيها هذه الثقة. إليك البنود العشرة في لمحة:

💡 ملاحظة حول التسمية: تُسمّي صفحة نظرة عامة على المشروع الإدخال السادس "حقن الأوامر النصية عبر حمولات سياقية"، بينما عنوان صفحته التفصيلية لـ MCP06 هو "تحويل مسار النية". كلاهما يشير إلى الخانة نفسها، وتستخدم هذه المقالة عنوان الصفحة التفصيلية.

الأسرار والصلاحيات والأدوات المسمومة

MCP01: سوء إدارة التوكنات وكشف الأسرار

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

سيناريو OWASP: يُدرج مطوّر سرًا في الكود أثناء الاختبار، فيقرأه خادم MCP عند بدء التشغيل، ثم يطبعه المساعد لاحقًا في رد على شخص آخر.

ما الذي يجب فعله:

• أصدر توكنات قصيرة العمر ومحدودة النطاق بدلًا من التوكنات الدائمة.
• شغّل فحص الأسرار على المستودعات وخطوط CI.
• أبقِ الأسرار بعيدة عن أوصاف الأدوات والأوامر النصية النظامية وأمثلة الحمولات.
• ادوّر السر فورًا عند أي اشتباه في تسريبه.

💡 نصيحة: الأسرار ذات البادئة الثابتة سهلة التعقب. أسرار PicassoIA API تبدأ بالنص pia_sk_، لذا يمكن لقاعدة فحص من سطر واحد أن تُعلّم أي منها في أي مستودع. أضف قاعدة من النوع نفسه لكل مزوّد تستخدمه.

MCP02: تصعيد الصلاحيات عبر توسّع النطاق

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

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

ما الذي يجب فعله:

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

MCP03: تسميم الأدوات

تختار النماذج الأدوات بقراءة أسمائها وأوصافها، وهذا ما يجعل الأوصاف سطح هجوم. الأداة المسمومة تخفي تعليمات في بياناتها الوصفية أو مخططها أو مخرجاتها. في أبريل 2025 عرضت Invariant Labs الهجوم بأداة جمع بريئة، كان وصفها المخفي يأمر الوكيل بقراءة ملف إعداد MCP محلي وملف SSH الخاص، ثم تمرير المحتوى في معامل إضافي بينما يتحدث الرد عن الحساب.

والنسخة الأخطر هي سحب البساط (rug pull): تسلك الأداة سلوكًا جيدًا عند موافقتك عليها، ثم تغيّر وصفها بعد التثبيت.

ما الذي يجب فعله:

• ثبّت إصدارات الأدوات واحفظ بصمة (hash) لكل وصف عند وقت الموافقة.
• نبّه عند أي تغيير في وصف الأداة أو مخططها.
• اعرض على المستخدمين الوصف الكامل للأداة لا ملخصًا مختصرًا.
• فضّل الأدوات الموقّعة من ناشرين يمكنك تحديد هويتهم.

MCP04: هجمات سلسلة التوريد وعبث التبعيات

خادم MCP شيفرة كتبها شخص آخر وسحبها من سجل عام. الحزمة المخترقة أو المنتحلة تحصل على الوصول نفسه الذي تمنحه للحزمة الأصلية. في سبتمبر 2025، نسخت حزمة npm اسمها postmark-mcp تكامل Postmark الحقيقي وأضافت سطرًا واحدًا يرسل نسخة مخفية من كل بريد صادر إلى عنوان يتحكم فيه المهاجم. وصفه باحثو Koi Security بأنه أول خادم MCP خبيث يُرصد في البرية، وتشرح كتابة Snyk التفاصيل. وقد كانت تُنزَّل نحو 1,500 مرة أسبوعيًا قبل إزالتها.

ما الذي يجب فعله:

• احتفظ بقائمة مواد الذكاء الاصطناعي (AI bill of materials): كل خادم، وإصداره، ومصدره.
• ثبّت الإصدارات الدقيقة واقرأ الفرق قبل كل ترقية.
• ثبّت فقط من ناشرين يمكنك التحقق منهم، وفضّل الإصدارات الموقّعة.
• شغّل فحص التبعيات قبل اعتماد أي خادم، وشغّل الخوادم غير المألوفة داخل حاوية بلا وصول إلى الشبكة حتى تتم مراجعتها.

MCP05: حقن الأوامر وتنفيذها

تبني الوكلاء الأوامر من النصوص. وعندما يكون النص خاضعًا لسيطرة المهاجم (تعليق في قضية، أو اسم ملف، أو صفحة ويب)، تتولى الصدفة الباقي. وفقًا لتحليل Cycode للقائمة، فإن الثغرة CVE-2025-6514 في mcp-remote حملت درجة CVSS تبلغ 9.6، وأثرت على حزمة تجاوزت 437,000 تنزيل، وسمحت بحقن أوامر نظام التشغيل. وهي تقع على الحد الفاصل بين هذا البند وMCP04.

الفرق بين الخطر والأمان غالبًا سطر واحد:

import re
import subprocess

# Risky: untrusted text is spliced into a shell string
subprocess.run(f"git log --author={author}", shell=True)

# Safer: fixed command, argument list, validated input, no shell
if not re.fullmatch(r"[A-Za-z0-9._@][A-Za-z0-9 ._@-]{0,63}", author):
    raise ValueError("invalid author")
subprocess.run(["git", "log", "--author", author], shell=False, check=True)

نسخ الأمر النصي

ما الذي يجب فعله:

• فضّل واجهات API ذات معاملات على أوامر الصدفة.
• عندما يكون تنفيذ أمر ما أمرًا لا مفر منه، استخدم قوائم الوسائط والتحقق الصارم من المدخلات.
• طبّق سياسة الرفض الافتراضي لتحديد الأوامر التي يحق للخادم تشغيلها.
• ضع الخوادم المحلية في بيئة معزولة (sandbox) حتى يبقى أي حقن ناجح محصورًا في نطاق صغير.

النية المختطفة والأبواب المفتوحة

MCP06: تحويل مسار النية

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

أوضح حالة حقيقية جاءت من Invariant Labs في مايو 2025، ضد خادم GitHub MCP الرسمي. يفتح المهاجم قضية خبيثة في مستودع عام. وعندما يطلب مالك المستودع من وكيله النظر في القضايا المفتوحة، يقرأ الوكيل القضية، فيُحقن، ويسحب بيانات من مستودعات خاصة إلى سياقه، وينشرها في طلب سحب على المستودع العام. وصف الباحثون ذلك بأنه تدفق سام للوكيل، وقالوا إنه مشكلة في البنية وليس خللًا في شيفرة الخادم، واشتبهوا في أن كثيرين يختارون سياسة موافقة "السماح دائمًا"، وهي ما يزيل الفحص البشري.

ما الذي يجب فعله:

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

💡 نصيحة: المصنِّف طبقة واحدة، وليس الدفاع كله. Llama Guard 4 12B على PicassoIA نموذج لإدارة المحتوى يمكنه فحص النص قبل وصوله إلى وكيلك، لكنه مصنِّف للسلامة وليس أداة مخصصة لكشف الحقن، لذا أبقِ على الموافقات وأقل قدر من الصلاحيات قائمًا.

MCP07: مصادقة وتفويض غير كافيين

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

من الحالات الملموسة الثغرة CVE-2025-49596 في MCP Inspector التابع لشركة Anthropic، وقد صُنّفت بدرجة CVSS تبلغ 9.4. الإصدارات الأقل من 0.14.1 لم تكن تحوي أي مصادقة بين عميل Inspector ووسيطه، فكان بإمكان الطلبات غير الموثّقة تشغيل أوامر عبر stdio. وعند دمجها مع خلل في المتصفح وتزييف طلبات عبر المواقع، كان مجرد زيارة موقع خبيث كفيلًا بتشغيل شيفرة على جهاز مطور.

ما الذي يجب فعله:

• استخدم OAuth 2.1 مع المصادقة متعددة العوامل للأشخاص.
• تحقّق من جمهور التوكن لكل خادم، بحيث يفشل توكن صُنع لخادم واحد عند خادم آخر.
• امنح الخدمات هويات مُدارة بدلًا من الحسابات المشتركة.
• اربط الخوادم المحلية بعنوان localhost، واشترط توكنًا حتى هناك.
• تحقّق من الصلاحيات في كل استدعاء لأداة، لا مرة واحدة لكل جلسة.

البقع العمياء والخوادم الخفية

MCP08: غياب التدقيق والقياس عن بُعد

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

سجل استدعاءات الأدوات المفيد صغير. لكل استدعاء، سجّل:

ما الذي يجب فعله:

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

MCP09: خوادم MCP الخفية

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

أين تبحث أولًا:

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

ما الذي يجب فعله:

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

MCP10: حقن السياق وإفراط المشاركة

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

وقد حدث هذا فعلًا لمنتج حقيقي. ذكرت BleepingComputer أن Asana حذّرت المستخدمين في يونيو 2025 من أن خللًا منطقيًا في ميزة MCP الجديدة لديها كشف بيانات بعض المؤسسات لمؤسسات أخرى. تأثر نحو 1,000 عميل، وأوقفت Asana الميزة من 5 يونيو إلى 17 يونيو بينما تصلح الخلل. كان خطأً منطقيًا وليس اختراقًا، وكان الخلل قائمًا نحو شهر قبل أن تكتشفه Asana.

ما الذي يجب فعله:

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

أي المخاطر تُصلح أولًا

لا يمكنك إغلاق البنود العشرة كلها في أسبوع، لذا ابدأ من حيث يكون الضرر الأكبر والعمل الأقل.

أعلى أثر وأقل جهد

• MCP01: فعّل فحص الأسرار وقلّص عمر التوكنات.
• MCP07: ضع المصادقة أمام كل خادم، بما فيها الخوادم على localhost.
• MCP09: أحصِ كل خادم يشغّله فريقك اليوم. لا يمكنك حماية ما لم تعدّه.

أبطأ لكنه ضروري

• MCP03 وMCP04: التثبيت والتجزئة يتطلبان إعدادًا حقيقيًا، لكنهما يوقفان التغييرات الصامتة.
• MCP06: الموافقات وحواجز الحماية تحتاج إلى تصميم وضبط مستمر.
• MCP08 وMCP10: التسجيل والعزل يمسان البنية، لذا خطط لهما كمشاريع.
• MCP02 وMCP05: هذان بين الفئتين؛ شدّد النطاقات أثناء مراجعتك لكل خادم.

خطة تقوية لأسبوع واحد

💡 أخطاء شائعة: الموافقة على "السماح دائمًا" لتقليل النقرات، والوثوق بخادم لأن تنزيلاته كثيرة، وتسجيل كل شيء ما عدا معاملات الأدوات المهمة.

أنشئ مرئياتك الأمنية الخاصة

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

جرّبها على PicassoIA. افتح نموذج تحويل نص إلى صورة مثل Seedream 5 Pro أو Qwen Image 3 أو GPT Image 2، وصف شيئًا حقيقيًا واحدًا يمثّل الخطر لديك، وأضف الإضاءة والعدسة التي تريدها. ولّد عدة اختيارات، واختر الأوضح، وأدرجها في مراجعتك التالية. وإذا كنت تكتب الوثائق أيضًا، فيمكن للنماذج اللغوية الكبيرة على PicassoIA أن تساعدك في كتابة المسودة الأولى قبل أن تحررها بيدك.