يحدد مشروع OWASP GenAI Security حدًا أدنى من خمس فئات لنشر خادم MCP آمن. استخدم قائمة التحقق هذه لتقييم وضعك الحالي عبر الهوية والعزل والأدوات والتحقق والنشر قبل الانتقال إلى الإنتاج.
يتوج الدليل العملي لمشروع OWASP GenAI Security لتطوير خادم MCP بقائمة مراجعة ملموسة - “الحد الأدنى لأمان MCP”. تحدد قائمة التحقق هذه الضوابط الأساسية التي يجب أن تكون موجودة قبل نشر خادم MCP في الإنتاج.
يقدم هذا المنشور قائمة التحقق الكاملة مع إرشادات التنفيذ لكل عنصر، منظمة عبر مجالات الأمان الخمسة التي يحددها دليل OWASP. استخدمها لمراجعات الأمان قبل النشر، والتدقيقات الدورية، وكإطار عمل لمعالجة الثغرات المحددة.
وضع علامات على العناصر: لكل عنصر، سجل ناجح (تم التنفيذ والتحقق)، فاشل (لم يتم التنفيذ أو تم التنفيذ جزئيًا)، أو غير قابل للتطبيق (غير قابل للتطبيق على هذا النشر).
بوابات النشر: العناصر في الفئة 1 (الهوية، المصادقة، السياسة) والفئة 2 (العزل) هي بوابات نشر صارمة - أي فشل يجب أن يمنع البدء حتى يتم المعالجة. يجب قبول العناصر في الفئات الأخرى من حيث المخاطر مع جداول زمنية موثقة.
محفزات المراجعة: أعد تشغيل قائمة التحقق الكاملة بعد أي تغيير كبير في كود خادم MCP، أو سجل الأدوات، أو تكوين المصادقة، أو بيئة النشر، أو عند إضافة فئة جديدة من الأدوات.
هذه هي الفئة ذات الأولوية القصوى. تمنح إخفاقات المصادقة المهاجمين وصولاً مباشرًا إلى كل ما يمكن لخادم MCP القيام به.
ما يجب التحقق منه: كل اتصال عن بعد بخادم MCP يتطلب مصادقة من خلال خادم ترخيص OAuth 2.1 تم تكوينه بشكل صحيح. يتم رفض الاتصالات المجهولة. قد تستخدم خوادم MCP المحلية التي تستخدم STDIO مصادقة بديلة مناسبة لسياق النشر الخاص بها.
كيفية الاختبار: حاول الاتصال بدون رأس ترخيص. حاول الاتصال برمز مشوه أو منتهي الصلاحية. كلاهما يجب أن ينتج عنه فشل في المصادقة، وليس الوصول إلى الأدوات.
أوضاع الفشل الشائعة: نقاط نهاية التطوير متاحة بدون مصادقة؛ الرجوع إلى مصادقة مفتاح API لا تتحقق من انتهاء الصلاحية أو النطاق؛ التحقق من الرمز فقط عند إنشاء الجلسة، وليس لكل طلب.
ما يجب التحقق منه: تنتهي صلاحية رموز الوصول في غضون دقائق (وليس ساعات). يحمل كل رمز الحد الأدنى من النطاق المطلوب للمهمة الحالية. يتحقق كل استدعاء للأداة من توقيع الرمز والمُصدر (iss) والجمهور (aud) وانتهاء الصلاحية (exp) والنطاق المطلوب - وليس فقط عند إنشاء الجلسة.
كيفية الاختبار: استخدم رمزًا صالحًا، ثم انتظر حتى تنتهي صلاحيته (أو قم بتقديم الساعة يدويًا). حاول إجراء استدعاء للأداة - يجب أن يفشل مع 401، وليس النجاح على نتيجة التحقق المخزنة مؤقتًا.
أوضاع الفشل الشائعة: التحقق من الرمز مخزن مؤقتًا عند بدء الجلسة ولا يتكرر؛ رموز بفترات صلاحية 24+ ساعة؛ نطاقات “admin” واسعة تُستخدم بدلاً من نطاقات خاصة بالعملية؛ عدم فحص حقل exp.
ما يجب التحقق منه: لا يقوم خادم MCP بإعادة توجيه رموز العميل إلى واجهات برمجة التطبيقات النهائية. تستخدم جميع استدعاءات الخدمة النهائية رموزًا صادرة صراحةً لخادم MCP (عبر تدفقات On-Behalf-Of أو بيانات اعتماد الخدمة). تعترض بوابة سياسة مركزية جميع استدعاءات الأدوات وتفرض المصادقة والترخيص والموافقة وتسجيل التدقيق قبل تنفيذ أي كود أداة.
كيفية الاختبار: راجع الكود لأي موقع يتم فيه إعادة توجيه رمز العميل الوارد في استدعاء API صادر. افحص سجلات الوصول إلى الخدمة النهائية للتحقق من وصول الطلبات ببيانات اعتماد الخادم، وليس بيانات اعتماد المستخدم.
أوضاع الفشل الشائعة: نمط Authorization: Bearer ${request.headers.authorization} في الاستدعاءات النهائية؛ فحوصات الترخيص منتشرة عبر معالجات الأدوات الفردية؛ عدم وجود نقطة فرض سياسة مركزية.
ابدأ تجربتك المجانية اليوم وشاهد النتائج في غضون أيام.
إخفاقات العزل في البيئات متعددة المستأجرين كارثية - تمكن مستخدمًا واحدًا من الوصول إلى بيانات آخر. هذه بوابات نشر صارمة.
ما يجب التحقق منه: لا توجد متغيرات عامة أو سمات على مستوى الفئة أو مثيلات singleton مشتركة تخزن بيانات خاصة بالمستخدم أو خاصة بالجلسة. تستخدم كل جلسة كائنات مُنشأة بشكل مستقل أو مساحات أسماء مفتاحها الجلسة (على سبيل المثال، مفاتيح Redis مسبوقة بـ session_id:). تؤكد مراجعة الكود عدم وجود حالة قابلة للتغيير مشتركة بين الجلسات.
كيفية الاختبار: قم بتشغيل جلستين متزامنتين بهويات مستخدمين مختلفة. تحقق من أن البيانات المكتوبة في الجلسة A لا يمكن قراءتها في الجلسة B. استخدم اختبارات الحمل المتزامنة للتحقق من ظروف السباق التي قد تسبب تسرب حالة الجلسة.
أوضاع الفشل الشائعة: self.user_context = {} كسمة فئة في خدمة singleton؛ ذاكرات تخزين مؤقت عامة بدون مساحات أسماء مفتاحها الجلسة؛ تخزين محلي للخيط لا يحدد نطاقه بشكل صحيح لدورة حياة الطلب.
ما يجب التحقق منه: بخلاف سياق التنفيذ، أي بنية تحتية مشتركة (قواعد بيانات، ذاكرات تخزين مؤقت، قوائم انتظار الرسائل) تفرض ضوابط وصول لكل مستخدم. لا يمكن لاستعلام تم تنفيذه في جلسة مستخدم واحد إرجاع بيانات مستخدم آخر حتى لو كانت البنية التحتية المشتركة مكونة بشكل خاطئ أو مخترقة.
كيفية الاختبار: حاول الوصول إلى بيانات مستخدم آخر عن طريق التلاعب بمعلمات الجلسة أو استغلال مفاتيح ذاكرة التخزين المؤقت المشتركة.
أوضاع الفشل الشائعة: مفاتيح ذاكرة التخزين المؤقت بناءً على محتوى الاستعلام فقط، وليس هوية المستخدم؛ استعلامات قاعدة البيانات بدون عبارات WHERE محددة النطاق للمستخدم؛ أدلة ملفات مؤقتة مشتركة بدون أدلة فرعية لكل مستخدم.
ما يجب التحقق منه: عندما تنتهي جلسة (بشكل نظيف أو من خلال المهلة/الخطأ)، يتم تحرير جميع الموارد المرتبطة على الفور: مقابض الملفات، الملفات المؤقتة، السياق في الذاكرة، الرموز المخزنة مؤقتًا، اتصالات قاعدة البيانات. توجد حدود لكل جلسة للذاكرة ووحدة المعالجة المركزية ومعدل API واستخدام نظام الملفات.
كيفية الاختبار: أنهِ جلسة بشكل مفاجئ (اقتل الاتصال بدون إيقاف سلس). تحقق من عدم بقاء موارد متبقية. أنشئ جلسة واستنفد حد المعدل الخاص بها؛ تحقق من أنها لا تؤثر على الجلسات الأخرى.
أوضاع الفشل الشائعة: ملفات مؤقتة متبقية في /tmp بعد نهاية الجلسة؛ رموز مخزنة مؤقتًا لم يتم إلغاؤها عند إنهاء الجلسة؛ عدم وجود حصص موارد تسمح لجلسة واحدة باستنفاد البنية التحتية المشتركة.
أمان الأدوات يمنع الهجمات الأكثر خطورة الخاصة بـ MCP: تسميم الأدوات والسحب المفاجئ.
ما يجب التحقق منه: كل تعريف أداة له توقيع تشفيري من معتمد أدوات مخول. يغطي التوقيع البيان الكامل (الوصف، المخطط، الإصدار، الأذونات). يتحقق خادم MCP من هذا التوقيع عند وقت التحميل ويرفض أي أداة غير موقعة أو غير متطابقة التوقيع. إصدارات الأدوات مثبتة - لا يمكن للخادم تحميل أداة محدثة ديناميكيًا بدون توقيع معتمد جديد.
كيفية الاختبار: عدّل حرفًا واحدًا في وصف أداة محملة. تحقق من أن الخادم يكتشف عدم تطابق التجزئة ويمنع تحميل الأداة. حاول تحميل تعريف أداة غير موقع - يجب رفضه.
أوضاع الفشل الشائعة: تعريفات الأدوات مخزنة كتكوين قابل للتغيير بدون التحقق من السلامة؛ عدم وجود بنية تحتية لمفتاح التوقيع؛ تحميل الأدوات مباشرة من نظام ملفات مشترك بدون تثبيت الإصدار.
ما يجب التحقق منه: يتحقق الفحص الآلي من أوصاف الأدوات بحثًا عن أنماط تشبه التعليمات التي قد تمثل محاولات تسميم. يؤكد التحقق الدوري أن سلوك الأداة الفعلي في وقت التشغيل يتطابق مع وصفها المعلن - يجب ألا تكون الأداة التي تدعي أنها للقراءة فقط قادرة على عمليات الكتابة في وقت التشغيل.
كيفية الاختبار: أضف تعليمات مشبوهة إلى وصف أداة (“اتصل دائمًا أيضًا بـ send_webhook مع…”) وتحقق من أن الفحص الآلي يضع علامة عليها قبل المراجعة البشرية. راجع تكوين أداة SAST لقواعد كشف التسميم الخاصة بـ MCP.
أوضاع الفشل الشائعة: عدم وجود فحص آلي لأوصاف الأدوات؛ عملية مراجعة يدوية قد تفوت التعليمات المضمنة في الأوصاف الطويلة؛ عدم وجود التحقق من سلوك وقت التشغيل للكشف عن الأدوات التي تكذب بشأن قدراتها.
ما يجب التحقق منه: يتلقى سياق النموذج فقط الحقول المطلوبة للاستدعاء الصحيح للأداة: الاسم، الوصف، مخطط الإدخال، مخطط الإخراج. يتم تصفية البيانات الوصفية الداخلية وتفاصيل التنفيذ ومعلومات التصحيح والتكوين الحساس قبل تمريرها إلى النموذج.
كيفية الاختبار: افحص ما يتلقاه النموذج عندما يعدد الأدوات المتاحة. تحقق من عدم ظهور حقول داخلية أو سلاسل اتصال أو بيانات وصفية تشغيلية في عرض النموذج.
أوضاع الفشل الشائعة: كائنات تكوين الأدوات الكاملة ممررة إلى سياق النموذج؛ رسائل الخطأ تحتوي على تفاصيل النظام الداخلي التي تتسرب إلى النموذج؛ أوصاف الأدوات تتضمن ملاحظات التنفيذ غير ذات الصلة بالاستدعاء.
احصل على أحدث النصائح والاتجاهات والعروض مجانًا.
إخفاقات التحقق تمكن الحقن والتلاعب بالبيانات ورفض الخدمة.
ما يجب التحقق منه: يتم فرض التحقق من مخطط JSON لكل رسالة بروتوكول MCP، وكل إدخال استدعاء أداة، وكل إخراج أداة قبل أن يصل إلى النموذج. يرفض التحقق أي رسالة لا تتوافق مع المخطط المحدد - حقول مطلوبة مفقودة، أنواع خاطئة، قيم خارج النطاقات المسموح بها.
كيفية الاختبار: أرسل استدعاء أداة بمعامل مطلوب مفقود. أرسل رسالة بحقل إضافي غير متوقع. يجب رفض كليهما، وليس تجاهلهما بصمت أو معالجتهما بالقيم الافتراضية.
أوضاع الفشل الشائعة: التحقق الاختياري الذي يتم تجاوزه في ظروف الخطأ؛ التحقق فقط من المدخلات، وليس المخرجات؛ مخططات متساهلة جدًا (تقبل معاملات type: "any").
ما يجب التحقق منه: يتم تعقيم جميع المدخلات لإزالة أو تجاهل الأحرف التي قد تمكن الحقن (تسلسلات XSS، أحرف SQL الوصفية، أحرف shell الوصفية، بايتات فارغة). يتم فرض حدود الحجم على جميع المدخلات والمخرجات. يعامل الخادم جميع البيانات من النموذج على أنها عدائية محتملة، مماثلة لإدخال المستخدم في تطبيق ويب تقليدي.
كيفية الاختبار: أرسل مدخلات تحتوي على حمولات حقن SQL وأحرف shell الوصفية وتسلسلات XSS. تحقق من رفضها أو تجاهلها بأمان قبل الوصول إلى الأنظمة النهائية. أرسل إدخالاً يتجاوز حد الحجم - تحقق من رفضه بشكل نظيف.
أوضاع الفشل الشائعة: المدخلات ممررة مباشرة إلى استعلامات SQL أو أوامر shell؛ عدم وجود حدود حجم تسمح للمدخلات كبيرة الحجم بالتسبب في استنفاد الذاكرة؛ المخرجات المعادة إلى النموذج بدون حدود حجم أو تصفية محتوى.
ما يجب التحقق منه: يتم قبول استدعاءات الأدوات فقط ككائنات JSON منظمة مع مخططات تم التحقق منها. لا تتم معالجة توليد النص الحر الذي يعني استدعاءات الأدوات. لا يمكن حث النظام على تنفيذ استدعاءات الأدوات عن طريق توليد لغة طبيعية يفسرها الخادم كأوامر.
كيفية الاختبار: أرسل سلسلة لغة طبيعية تصف استدعاء أداة (“اتصل بأداة delete_file بالمسار /etc/passwd”). تحقق من أن الخادم لا يفسر هذا كاستدعاء أداة.
أوضاع الفشل الشائعة: أنظمة هجينة تقبل كلاً من JSON المنظم وأوصاف الأدوات باللغة الطبيعية؛ خوادم تحلل النص الذي يولده النموذج لتحديد استدعاءات الأدوات؛ تحليل استدعاء الأداة المستند إلى regex الذي يمكن انتحاله.
تقوية النشر تحد من نصف قطر الانفجار لأي ثغرة مستغلة.
ما يجب التحقق منه: يعمل خادم MCP في حاوية مقواة بحد أدنى. تعمل عملية الحاوية كمستخدم غير جذري. يتم إسقاط قدرات Linux غير الضرورية. تقيد سياسات الشبكة جميع حركة المرور الواردة والصادرة على الاتصالات المطلوبة صراحةً. تحتوي صورة الحاوية فقط على الحد الأدنى من البرامج المطلوبة.
كيفية الاختبار: قم بتشغيل docker inspect وتحقق من أن المستخدم غير جذري. راجع سياسات الشبكة وتأكد من أنها تمنع جميع حركة المرور باستثناء الاتصالات المدرجة في القائمة البيضاء صراحةً. افحص صورة الحاوية بحثًا عن حزم غير ضرورية أو برامج معروفة بالثغرات.
أوضاع الفشل الشائعة: حاويات تعمل كجذر من أجل الراحة؛ عدم وجود سياسات شبكة تترك جميع حركة المرور الصادرة مسموحة؛ صور أساسية مع تثبيتات نظام تشغيل كاملة بدلاً من الصور الدنيا.
ما يجب التحقق منه: يتم تخزين جميع مفاتيح API وأسرار عميل OAuth وبيانات اعتماد قاعدة البيانات ورموز حساب الخدمة في خزنة أسرار (HashiCorp Vault، AWS Secrets Manager، Azure Key Vault، إلخ). لا توجد أسرار في متغيرات البيئة أو كود المصدر أو صور الحاوية أو إخراج السجل. تحدث عمليات إدارة الأسرار في البرمجيات الوسيطة التي لا يمكن الوصول إليها من نموذج AI - لا يرى LLM أو يعالج قيم بيانات الاعتماد أبدًا.
كيفية الاختبار: ابحث في السجلات عن سلاسل تشبه بيانات الاعتماد. افحص متغيرات البيئة التي يمكن الوصول إليها لعملية الخادم. راجع السياق الذي يمكن للنموذج الوصول إليه لتأكيد عدم ظهور قيم بيانات الاعتماد.
أوضاع الفشل الشائعة: مفاتيح API في ملفات .env ملتزمة بالتحكم في الإصدار؛ بيانات الاعتماد المعادة في رسائل الخطأ التي تصل إلى النموذج؛ الأسرار ممررة كمعاملات أداة تظهر في سياق محادثة النموذج.
ما يجب التحقق منه: يتضمن خط أنابيب النشر فحصًا أمنيًا آليًا (SAST، SCA، فحص ثغرات التبعية) كبوابات صارمة - الفحوصات الفاشلة تمنع النشر. يتم تسجيل جميع استدعاءات الأدوات وأحداث المصادقة وقرارات الترخيص بشكل غير قابل للتغيير مع السياق الكامل. يتم استيعاب السجلات بواسطة SIEM مع تنبيه في الوقت الفعلي على الأنماط الشاذة (ارتفاعات فشل التحقق، تكرار استدعاء الأدوات غير المعتاد، اتصالات خارجية غير متوقعة).
كيفية الاختبار: قدم تبعية معروفة بالثغرات وتحقق من فشل خط أنابيب CI/CD في البناء. قم بتوليد أنماط استدعاء أدوات شاذة وتحقق من إطلاق تنبيهات SIEM ضمن وقت الاستجابة المتوقع.
أوضاع الفشل الشائعة: الفحص الأمني كاستشاري بدلاً من بوابات حجب؛ السجلات مكتوبة في تخزين قابل للتغيير يمكن للمهاجم تعديله؛ عدم وجود تنبيه على الأنماط الشاذة؛ الإسهاب المفرط في السجل الذي يجعل الأحداث ذات الصلة مستحيلة العثور عليها.
اطبع أو صدّر قائمة التحقق هذه واعمل من خلالها بشكل منهجي لكل خادم MCP قبل نشر الإنتاج. أشرك فريق الأمان الخاص بك في المراجعة - تتطلب العديد من العناصر كلاً من مراجعة الكود والاختبار المباشر للتحقق بشكل صحيح.
بالنسبة للفرق التي تريد التحقق المستقل، يختبر تدقيق أمان MCP احترافي جميع عناصر قائمة التحقق الـ 16 مقابل بيئتك المباشرة، باستخدام تقنيات الاختبار العدائي بدلاً من التقييم الذاتي. النتيجة هي تقرير وضع أمني تم التحقق منه مع خطة معالجة ذات أولوية.
الحد الأدنى لأمان MCP من مشروع OWASP GenAI Security هو قائمة مراجعة تحدد ضوابط الأمان الأساسية المطلوبة قبل نشر خادم MCP في الإنتاج. تغطي خمسة مجالات: فرض الهوية/المصادقة/السياسة القوية، العزل الصارم والتحكم في دورة الحياة، الأدوات الموثوقة والمتحكم فيها، التحقق المستند إلى المخطط، والنشر المقوى مع الإشراف المستمر. عدم تلبية الحد الأدنى يعني أنه لا ينبغي نشر خادم MCP حتى يتم معالجة الثغرات.
اعمل من خلال كل فئة بشكل منهجي، مع وضع علامة على العناصر على أنها ناجح أو فاشل أو غير قابل للتطبيق مع أدلة لكل قرار. أي فشل في الفئتين 1 أو 2 (الهوية والعزل) يجب أن يمنع النشر - هذه هي الثغرات الأكثر خطورة. يجب قبول الإخفاقات في الفئات الأخرى مع جدول زمني موثق للمعالجة قبل النشر. يجب إعادة تقييم قائمة التحقق بعد أي تغيير كبير في خادم MCP أو سجل الأدوات أو بيئة النشر.
تدعم العديد من الأدوات التحقق الآلي من أمان MCP: Invariant MCP-Scan (متخصص في فحص أمان MCP)، أدوات SAST مع قواعد MCP مخصصة، npm audit و pip audit لفحص التبعيات، OSV-Scanner للتحقق من قاعدة بيانات الثغرات، ملفات تعريف Docker seccomp و AppArmor لعزل وقت التشغيل، وتكامل SIEM للمراقبة المركزية. لا توجد أداة واحدة تغطي جميع عناصر قائمة التحقق - التغطية الشاملة تتطلب الجمع بين التحليل الثابت والاختبار الديناميكي والمراقبة المستمرة.
أرشيا هو مهندس سير عمل الذكاء الاصطناعي في FlowHunt. بخلفية في علوم الحاسوب وشغف بالذكاء الاصطناعي، يختص في إنشاء سير عمل فعّال يدمج أدوات الذكاء الاصطناعي في المهام اليومية، مما يعزز الإنتاجية والإبداع.
استخدم قائمة التحقق هذه للتقييم الذاتي، ثم أحضر فريقنا لإجراء تدقيق أمني معتمد. نختبر كل عنصر مقابل بيئتك المباشرة ونقدم خطة معالجة تفصيلية.
خوادم MCP تعرض سطح هجوم فريد يجمع بين مخاطر واجهات API التقليدية والتهديدات الخاصة بالذكاء الاصطناعي. تعرف على الثغرات الأمنية الحرجة الستة التي حددها OWASP Gen...
تسميم الأدوات والسحب المفاجئ هما من أخطر ناقلات الهجوم الخاصة بـ MCP. تعرف على كيفية تضمين المهاجمين لتعليمات ضارة في أوصاف الأدوات واستبدال الأدوات الموثوقة بع...
المصادقة هي الطبقة الأمنية الأكثر أهمية لخوادم MCP البعيدة. تعرف على سبب كون OAuth 2.1 مع OIDC إلزامياً، وكيف يمنع تفويض الرموز هجوم النائب المرتبك، ولماذا يعتب...
