حل چالش امنیتی احراز هویت در MCP؛ چگونه به کلاینت‌های شخصی اعتماد کنیم؟ — Letting users trust their own MCP clients, without opening a phishing hole
خلاصه
این مقاله چالش‌های امنیتی پروتکل Model Context Protocol یا همان MCP را در زمان احراز هویت OAuth بررسی می‌کند. نویسنده راهکاری ارائه می‌دهد تا کاربران بتوانند به کلاینت‌های شخصی خود اعتماد کنند، بدون آنکه در دام حملات فیشینگ یا تغییر مسیر آزاد (Open Redirect) بیافتند.
مقدمه و زمینه
اگر در حال توسعه یک ایجنت شخصی، ربات Slack یا یک کلاینت سفارشی MCP هستید، احتمالاً با چالش اتصال آن به فایل‌ها و منابع خود مواجه شده‌اید. پروتکل Model Context Protocol یا همان MCP از استاندارد احراز هویت OAuth استفاده می‌کند؛ به این صورت که کلاینت خودش را ثبت می‌کند، مرورگر را باز می‌کند و شما با کلیک روی گزینه تأیید، یک توکن دسترسی دریافت می‌کنید.
اما در عمل، این فرآیند اغلب در قدم اول شکست می‌خورد. سرورهای MCP معمولاً آدرس بازگشت یا همان redirect_uri را محدود به لیست مشخصی از ارائه‌دهندگان بزرگ مانند Claude یا ChatGPT می‌کنند. دلیل این سخت‌گیری، جلوگیری از حملات فیشینگ است. اگر سرور هر آدرسی را بپذیرد، مهاجمان می‌توانند یک کلاینت جعلی ثبت کنند و با یک کلیک ساده، به اطلاعات حساب کاربر دسترسی پیدا کنند.
چالش امنیتی و آسیب‌پذیری‌های OAuth در MCP
مشکل اینجاست که سرورهای MCP بین دو قطب افراطی گیر افتاده‌اند:
- سرورهای کاملاً بسته: فقط اجازه استفاده از کلاینت‌های رسمی و از پیش‌تأییدشده را می‌دهند و توسعه‌دهندگان مستقل را پشت در نگه می‌دارند.
- سرورهای کاملاً باز: اجازه ثبت نام آنلودد و دایرکتوری‌های دلخواه را می‌دهند که طبق مطالعات امنیتی، بخش بزرگی از سرورهای واقعی را آسیب‌پذیر کرده است.
یک مهاجم می‌تواند با ثبت یک کلاینت جعلی با نامی آشنا و ارسال یک لینک ساختگی، کاربر را وادار به تأیید دسترسی کند. در این حالت، کد احراز هویت به سرور مهاجم ارسال شده و توکن کاربر به سرقت می‌رود. این سناریو پیش‌تر روی سرویس‌های واقعی مانند Square و ابزارهای مشابه گزارش شده بود. همچنین، خطاهای احراز هویت نیز گاهی به همان آدرس مخرب ارسال می‌شوند و سرور را به یک Open Redirector تبدیل می‌کنند.
راهکار پیشنهادی: اعتماد مبتنی بر کاربر در زمان Authorize
برای حل این معضل، رویکرد جدیدی پیشنهاد شده است که به جای اعتبارسنجی در زمان ثبت‌نام (Registration)، تصمیم‌گیری را به مرحله درخواست مجوز یا همان authorize موکول می‌کند؛ یعنی زمانی که کاربر نهایی شناسایی شده است.
جزئیات فنی این معماری به شرح زیر است:
- اعتماد سطح کاربر: علاوه بر لیست سراسری اپراتور، هر کاربر می‌تواند تعداد محدودی (مثلاً ۱۰ عدد) آدرس
httpsدقیق برای حساب خودش تعریف کند. - مدیریت خطاها: هیچ کد خطا یا پاسخ نامعتبری به آدرس‌های تأییدنشده ارسال نمی‌شود و خطاهای استاندارد در هاست خود سرور مدیریت می‌شوند.
- تأیید دستی و آگاهی‌رسانی: افزودن آدرس جدید نیازمند تایپ دستی هاست توسط کاربر است و هر بار که آدرسی اضافه می‌شود، ایمیل هشدار برای کاربر ارسال می‌گردد.
- ابطال آنی: اگر کاربری یک آدرس را حذف کند، تمام دسترسی‌ها و کدهای در حال انتظار مربوط به آن بلافاصله منقضی می‌شوند.
- تطابق دقیق: هیچ‌گونه Wildcard یا انعطاف‌پذیری در پورت‌ها پذیرفته نمی‌شود و تطابق URL باید کاملاً دقیق (Exact Match) باشد.
دیدگاه جامعه توسعه‌دهندگان (Hacker News)
در بحث‌های Hacker News، توسعه‌دهندگان به این نکته اشاره کردند که بسیاری از این مشکلات ناشی از برخورد دوباره با چالش‌های کلاسیک استاندارد OAuth است. برخی کاربران معتقدند که برای حساب‌های مصرف‌کننده نهایی، محدود کردن کلاینت‌های سفارشی یک تصمیم محافظه‌کارانه و امن است، در حالی که در محیط‌های سازمانی نیاز به مدیریت دقیق‌تر و کنترل توسط ادمین‌ها وجود دارد.
چرا این موضوع برای مهندسان نرم‌افزار اهمیت دارد؟
با فراگیر شدن ایجنت‌های هوش مصنوعی و ابزارهای مبتنی بر MCP، امنیت لایه اتصال و دسترسی به داده‌های حساس (مثل سطل‌های S3 یا پایگاه‌های داده) حیاتی است. توسعه‌دهندگان سیستم‌های ابری و پروتکل‌های احراز هویت باید بین تجربه توسعه‌دهنده (Developer Experience) و امنیت سطح بالا تعادل ایجاد کنند و از آسیب‌پذیری‌هایی نظیر Open Redirect و سرقت توکن جلوگیری نمایند.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل