DeepSeek Harness به یک مهاجم در محیط ایزوله (sandbox) اجازه داد تا تنها با تغییر هدر HTTP Host به 127.0.0.1، دستورات دلخواه را اجرا کند، که در مقیاس CVSS امتیاز 9.4 را کسب میکند. این نقص نشان میدهد که چگونه یک تصمیم اشتباه در اعتماد میتواند یک مرز حفاظتی را به یک درب پشتی باز تبدیل کند.
چگونه این باگ نفوذ کرد
کد آسیبپذیر در یک تابع واحد قرار دارد که هدر Host درخواست را میخواند و اگر مقدار آن برابر با آدرس loopback باشد، با درخواست بهگونهای برخورد میکند که گویی از ماشین محلی ارسال شده است.
مهاجمی که میتواند کدی را در محیط ایزوله اجرا کند، نیازی به یک پیلود (payload) پیچیده ندارد. با ارسال تنها یک درخواست HTTP با Host: 127.0.0.1 ، بکاند تصور میکند که فراخوانی از خودِ میزبان (host) منشأ گرفته است و تمام اعلانهای امنیتی، بررسیهای محدودیت نرخ (rate-limit) و مراحل اعتبارسنجی دستور را نادیده میگیرد. نتیجه: اجرای بدون محدودیت دستورات بدون نیاز به هیچ تعامل دیگری.
چرا اعتماد به هدرها خطرناک است
هدرها رشتههای متنی سادهای هستند که توسط فراخواننده (caller) ارسال میشوند. چه نام فیلد Host باشد، چه X-Forwarded-For یا هر نام سفارشی دیگر، کلاینت میتواند آن را به هر مقداری که میخواهد تنظیم کند. تنها منبع قابل اعتماد برای تشخیص اینکه یک اتصال واقعاً از کجا آمده است، لایه انتقال (transport layer) است؛ یعنی همان آدرس IP منبع سوکت که سیستمعامل هنگام تکمیل دستتکانی (handshake) TCP ثبت میکند.
وقتی یک اپلیکیشن تصمیم میگیرد بدون تأیید اینکه یک پروکسی شناختهشده و با پیکربندی صحیح آن را تزریق کرده است، به هدر اعتماد کند، در واقع کلیدهای دسترسی کامل را به دست مهاجم میدهد. باگ DeepSeek Harness یک مثال کلاسیک از این اشتباه است.
تأثیر در دنیای واقعی: مثال shell.online
پروژه متنباز shell.online که یک ترمینال مبتنی بر وب ارائه میدهد، اخیراً با همین مشکل مواجه شده و آن را مستند کرده است. این پروژه از یک پرچم پیکربندی به نام TRUST_PROXY استفاده میکند:
- TRUST_PROXY = 0 – اپلیکیشن هدر X-Forwarded-For را نادیده میگیرد و به آدرس راه دور (remote address) سوکت تکیه میکند. این کار از جعل آدرس IP توسط کلاینت برای دور زدن محدودیتهای نرخ یا جعل هویت به عنوان یک کاربر مورد اعتماد جلوگیری میکند.
- TRUST_PROXY = 1 – اپلیکیشن به هدر X-Forwarded-For به عنوان هویت کلاینت اعتماد میکند. اگر سرویس پشت یک پروکسی واقعی که این هدر را پاکسازی (sanitize) میکند نباشد، یک مهاجم میتواند در هر درخواست یک آدرس IP جدید ارائه دهد و بهطور مؤثری هرگونه محدودیت بر اساس IP را بازنشانی کند.
باگ DeepSeek دقیقاً مشابه این سناریو است: کد بهگونهای به Host اعتماد میکرد که انگار یک پروکسی آن را تنظیم کرده است، در حالی که سرویس میتوانست مستقیماً قابل دسترسی باشد.
اقداماتی که توسعهدهندگان باید انجام دهند
- هر جایی را که هدرهای ارسالی از سوی کلاینت را میخوانید، بازرسی کنید. مشخص کنید که به کدام هدرها به عنوان منبع معتبر اعتماد میکنید (مانند Host، X-Forwarded-For، X-Real-IP) و تأیید کنید که یک پروکسی مورد اعتماد تضمین میکند که آنها را پیش از رسیدن به اپلیکیشن شما بازنویسی میکند.
- تا حد امکان تصمیمات امنیتی را به آدرس سوکت گره بزنید. از IP منبع ارائه شده توسط سیستمعامل برای احراز هویت، محدودیت نرخ و بررسیهای کنترل دسترسی استفاده کنید.
- پرچمهای اعتماد به پروکسی (proxy-trust) را تنها زمانی فعال کنید که یک پروکسی معکوس (reverse proxy) با پیکربندی صحیح در مقابل سرویس قرار داشته باشد. اگر اپلیکیشن را مستقیماً اجرا میکنید، این پرچمها را غیرفعال نگه دارید.
- توپولوژی استقرار مورد نیاز را مستند کنید. این کار را در فایل README یا راهنمای استقرار پروژه خود انجام دهید تا کاربرانی که از سرویس بهصورت خودمیزبان (self-host) استفاده میکنند، از الزامات مربوط به اعتماد به پروکسی مطلع شوند.
- از ابزارهای تحلیل ایستا (static-analysis) یا بازبینی کد استفاده کنید که استفاده مستقیم از هدرها برای تصمیمات امنیتی را بدون وجود منطق تأیید پروکسی، علامتگذاری میکنند.
آنچه باید در آینده زیر نظر داشت
جوامعی که سرویسهای وب خودمیزبان (self-hosted) ارائه میدهند، احتمالاً پس از این حادثه، تنظیمات اعتماد به پروکسی خود را بازبینی خواهند کرد.
درس اصلی بسیار روشن است: هرگز اجازه ندهید تکهای از متن که هر کسی در اینترنت میتواند بنویسد، وضعیت امنیتی سیستم شما را تعیین کند. به لایه شبکه اعتماد کنید، نه به لایه درخواست.