المصادقة هي الطبقة الأمنية الأكثر أهمية لخوادم MCP البعيدة. تعرف على سبب كون OAuth 2.1 مع OIDC إلزامياً، وكيف يمنع تفويض الرموز هجوم النائب المرتبك، ولماذا يعتبر تمرير الرموز أحد أخطر الأنماط في تكاملات الذكاء الاصطناعي.
المصادقة هي البوابة التي تحدد ما إذا كانت قدرات خادم MCP القوية متاحة للمستخدمين الشرعيين أو للمهاجمين. إذا أخطأت في ذلك، تصبح كل عناصر التحكم الأمنية الأخرى غير ذات صلة — خادم MCP غير مصادق عليه أو مصادق عليه بشكل سيئ مع وصول إلى البريد الإلكتروني والملفات وقواعد البيانات هو ثغرة أمنية حرجة بغض النظر عن مدى تحصينك لكل شيء آخر.
يحدد دليل مشروع OWASP GenAI Security المصادقة والتفويض كأحد المجالات الأمنية الثمانية الأساسية لخوادم MCP، مع متطلبات محددة تتجاوز ما يطبقه معظم المطورين افتراضياً. يشرح هذا المنشور سبب وجود هذه المتطلبات وكيفية تنفيذها بشكل صحيح.
تواجه خوادم MCP مشهد مصادقة أكثر تعقيداً من الخدمات التقليدية لأنها تتوسط بين عدة أطراف رئيسية:
تتطلب كل من هذه العلاقات ضوابط المصادقة والتفويض الخاصة بها. يمكن استغلال الضعف في أي رابط لتجاوز الآخرين.
بالنسبة لخوادم MCP البعيدة — تلك التي يتم الوصول إليها عبر شبكة بدلاً من STDIO المحلي أو مقابس Unix — دليل OWASP GenAI واضح: OAuth 2.1 مع OIDC إلزامي، وليس اختيارياً.
هذا المتطلب موجود لأن:
يوفر OAuth 2.1 تحكماً صريحاً في النطاق. يعلن كل رمز وصول بالضبط عن الموارد والإجراءات التي يفوضها. يمكن لخادم MCP التحقق في وقت استدعاء الأداة من أن الرمز المقدم لديه النطاق المحدد المطلوب لهذا الإجراء — ليس فقط أن المستخدم مصادق عليه، ولكن أنه مفوض لهذه العملية المحددة.
يوفر OIDC هوية تشفيرية. يضيف OpenID Connect تأكيدات الهوية (رمز المعرف) التي يمكن لخادم MCP التحقق منها دون رحلة ذهاب وإياب إلى مزود الهوية. يتحقق الخادم من iss (المُصدر)، وaud (الجمهور)، وexp (انتهاء الصلاحية)، والتوقيع على كل طلب.
رموز OAuth 2.1 قصيرة العمر بالتصميم. تؤكد مواصفات OAuth الحديثة (التي توحد وتحل محل أفضل ممارسات OAuth 2.0) على رموز الوصول قصيرة العمر التي يجب تحديثها بانتظام. هذا يحد من نافذة الضرر إذا تم اختراق رمز.
لا تتحقق من الرموز فقط عند إنشاء الجلسة. تحقق من كل استدعاء أداة:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
لا تخزن نتائج التحقق مؤقتاً عبر الطلبات. قد يتم إلغاء رمز كان صالحاً عند بداية الجلسة في منتصف الجلسة.
في البيئات التي تتغير فيها عملاء MCP بشكل متكرر (على سبيل المثال، مساعدي ذكاء اصطناعي مختلفين يتصلون بنفس الخادم)، فإن مفاتيح API الثابتة أو الأسرار المشتركة مسبقاً غير كافية. استخدم تسجيل العميل الديناميكي مع OAuth 2.1 أو OIDC للتحقق من هوية العميل في وقت الاتصال. قوائم السماح أو سياسات الاتصال المشفرة أو TLS المتبادل (mTLS) مناسبة للعلاقات الثابتة المعروفة بين عملاء وخوادم محددة.
ابدأ تجربتك المجانية اليوم وشاهد النتائج في غضون أيام.
النائب المرتبك هو ثغرة أمنية كلاسيكية في التفويض مع مظهر خطير بشكل خاص في بنى MCP. يستغل الهجوم غموض سلطة من يتصرف به خادم MCP.
ضع في اعتبارك هذا السيناريو:
عندما تطلب أليس من مساعد الذكاء الاصطناعي “تلخيص مجلد مشروعي”، يستخدم الخادم رمز أليس للوصول إلى ملفاتها — سلوك صحيح. ولكن إذا خدع مهاجم الخادم لإجراء طلب باستخدام بيانات اعتماد الخدمة الخاصة به (ربما من خلال هجوم تسميم الأداة أو حقن موجه غير مباشر)، يتم استخدام أذونات الخادم المرتفعة للوصول إلى الملفات التي لا يُصرح لأليس برؤيتها.
الخادم هو “النائب المرتبك” — لقد تم خداعه لاستخدام سلطته نيابة عن شخص ليس لديه تلك السلطة، ويعمل كوكيل لتصعيد الامتيازات.
تعيد العديد من تطبيقات MCP توجيه رمز العميل إلى واجهات برمجة التطبيقات النهائية للبساطة. يبدو هذا بديهياً — يمثل رمز المستخدم أذونات المستخدم، لذا فإن استخدامه لجميع المكالمات النهائية يحافظ على التحكم الصحيح في الوصول.
المشكلة: قد تمنح واجهات برمجة التطبيقات النهائية التي تعترف بخادم MCP كوسيط موثوق به الطلبات باستخدام مستوى هوية الخادم، وليس مستوى رمز المستخدم المعاد توجيهه. وإذا تصرف خادم MCP من تلقاء نفسه — من خلال اتخاذ قرارات الذكاء الاصطناعي التي لم يطلبها المستخدم صراحةً — فقد يستخدم بيانات اعتماده الخاصة بدلاً من رمز المستخدم.
يؤدي إعادة توجيه رموز المستخدم أيضاً إلى:
بدلاً من إعادة توجيه رموز العميل، يجب على خادم MCP الحصول على رموزه الخاصة للوصول إلى الخدمة النهائية باستخدام تدفق نيابة عن (OBO) لـ OAuth:
يصادق المستخدم على عميل MCP → يحصل العميل على رمز وصول المستخدم
يقدم عميل MCP رمز المستخدم إلى خادم MCP
يستبدل خادم MCP رمز المستخدم برمز خادم عبر تدفق OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
يستخدم خادم MCP رمز OBO الخاص به للمكالمات النهائية
رمز OBO:
يقدم دليل OWASP GenAI توصية محددة: إصدار رموز وصول بأعمار تُقاس بالدقائق، وليس بالساعات. ينطبق هذا على كل من الرموز التي يقبلها خادم MCP من العملاء والرموز التي يحصل عليها للوصول إلى الخدمة النهائية.
رمز الوصول المسروق صالح طوال عمره الكامل بغض النظر عما إذا كان المستخدم الشرعي قد سجل الخروج أو غير كلمة المرور أو ألغى جلسته. رمز 24 ساعة مسروق في بداية الجلسة يمنح المهاجم 24 ساعة من الوصول المستمر. رمز 5 دقائق مسروق في منتصف الجلسة يمنح 5 دقائق على الأكثر.
تفرض الرموز قصيرة العمر أيضاً أحداث إعادة مصادقة منتظمة، والتي توفر فرصاً لـ:
يجب أن يحمل كل رمز فقط النطاقات المطلوبة للعملية المحددة التي يتم تنفيذها. لا تصدر رمزاً بنطاق read:files write:files delete:files عندما يحتاج استدعاء الأداة الحالي فقط إلى read:files. هذا يحد من الضرر إذا تم اعتراض الرمز أو تم التلاعب بالنموذج لإجراء استدعاءات أدوات غير متوقعة.
def get_tool_token(user_id: str, tool_name: str) -> str:
# ربط الأداة بالحد الأدنى من النطاقات المطلوبة
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # عمر 5 دقائق
)
احصل على أحدث النصائح والاتجاهات والعروض مجانًا.
خطأ شائع هو استخدام معرفات الجلسة كوكلاء تفويض: إذا كان الطلب يحمل معرف جلسة صالح، يفترض الخادم أنه مفوض. هذا يخلط بين إدارة الحالة والتحقق من الهوية.
النموذج الصحيح: تدير معرفات الجلسة الحالة المحادثة. يتم التحقق من التفويض بشكل مستقل في كل طلب من خلال التحقق من مطالبات رمز OAuth. حتى الطلب الذي يحمل معرف جلسة صالح يجب أن يقدم رمز OAuth صالحاً وغير منتهي الصلاحية ومحدد النطاق بشكل صحيح قبل السماح بأي استدعاء أداة.
هذا مهم لأن معرفات الجلسة يمكن سرقتها أو تخمينها أو إعادة تشغيلها بطرق لا تستطيع رموز OAuth — التي تحمل ضمانات سلامة تشفيرية — القيام بها.
بدلاً من تنفيذ فحوصات التفويض المتناثرة في جميع معالجات الأدوات الفردية، يوصي دليل OWASP GenAI ببوابة سياسة مركزية تقوم بـ:
يضمن المركزية تطبيق السياسات بشكل متسق عبر جميع الأدوات والوكلاء. يمكن نسيان أو تجاوز فحص التفويض الخاص بالأداة أثناء التطوير؛ لا يمكن تجاوز فحص البوابة.
بالنسبة لخوادم MCP البعيدة، فإن الحد الأدنى من شريط أمان المصادقة هو:
يُطلب OAuth 2.1 لخوادم MCP البعيدة لأنه يوفر تفويضاً مفوضاً مع تحكم صريح في النطاق، ورموزاً قصيرة العمر، والتحقق التشفيري، وتأكيدات هوية موحدة (عبر OIDC). تفتقر الطرق الأبسط مثل مفاتيح API أو ملفات تعريف ارتباط الجلسة إلى دقة النطاق اللازمة لتنفيذ الوصول بأقل امتيازات، ولا توفر ضمانات هوية تشفيرية، ويصعب إلغاؤها بشكل دقيق عند انتهاء الجلسة.
النائب المرتبك هو هجوم تصعيد امتيازات حيث يتم خداع خادم MCP لاستخدام امتيازاته الخاصة (الأعلى) لتنفيذ إجراءات لا يُصرح للمستخدم الطالب بتنفيذها. يحدث هذا عند استخدام تمرير الرموز — حيث يقوم الخادم بإعادة توجيه رمز المستخدم إلى واجهات برمجة التطبيقات النهائية، والتي قد تمنح المستخدم وصولاً لا ينبغي أن يحصل عليه بناءً على حالة الخادم الموثوقة. الحل هو استخدام تدفقات رموز نيابة عن (On-Behalf-Of) حيث يتم إصدار الرموز صراحةً لنطاق وصول خادم MCP المحدد.
تمرير الرموز يعني أن خادم MCP يعيد توجيه رمز مصادقة العميل مباشرة إلى واجهات برمجة التطبيقات النهائية، بدلاً من استخدام بيانات اعتماد الخادم الصادرة الخاصة به. هذا خطير لأن: (1) يكسر مسارات التدقيق — تشاهد الأنظمة النهائية رمز المستخدم، وليس خادم MCP، مما يجعل من المستحيل نسب الإجراءات إلى الخادم؛ (2) يتجاوز سياسات الوصول الخاصة بخادم MCP؛ (3) يخلق ثغرة النائب المرتبك إذا كانت واجهة برمجة التطبيقات النهائية تثق في هوية خادم MCP أكثر من هوية المستخدم؛ و(4) إذا تم اختراق خادم MCP، يحصل المهاجم على وصول إلى رموز المستخدم المعاد توجيهها لجميع الخدمات النهائية المتصلة.
يوصي دليل OWASP GenAI برموز ذات أعمار تُقاس بالدقائق، وليس بالساعات أو الأيام. تحد أعمار الرموز الأقصر من نافذة الاستغلال إذا تم سرقة رمز أو اختراق جلسة. يجب على كل استدعاء أداة إعادة التحقق من توقيع الرمز والجمهور وانتهاء الصلاحية — وليس الاعتماد على التحقق المخزن مؤقتاً من بداية الجلسة.
أرشيا هو مهندس سير عمل الذكاء الاصطناعي في FlowHunt. بخلفية في علوم الحاسوب وشغف بالذكاء الاصطناعي، يختص في إنشاء سير عمل فعّال يدمج أدوات الذكاء الاصطناعي في المهام اليومية، مما يعزز الإنتاجية والإبداع.
يقوم فريق الأمان لدينا بتقييم تكوينات مصادقة MCP، ومعالجة الرموز، وتدفقات التفويض وفقاً لمعايير OWASP GenAI. حدد الثغرات قبل أن يفعل المهاجمون.
خوادم MCP تعرض سطح هجوم فريد يجمع بين مخاطر واجهات API التقليدية والتهديدات الخاصة بالذكاء الاصطناعي. تعرف على الثغرات الأمنية الحرجة الستة التي حددها OWASP Gen...
يجلب خادم MCP القابل للتصديق إثبات النزاهة عن بُعد والحوسبة السرية إلى سير عمل FlowHunt، مما يسمح لوكلاء الذكاء الاصطناعي والعملاء بالتحقق من سلامة الخادم قبل ا...
تعلّم كيفية بناء ونشر خادم بروتوكول سياق النماذج (MCP) لربط نماذج الذكاء الاصطناعي مع الأدوات ومصادر البيانات الخارجية. دليل خطوة بخطوة للمبتدئين والمطورين المت...