شما روی پیوندی به یک مقاله فنی، ابزار آنلاین یا پیش‌نمایش یک صفحه وب کلیک می‌کنید. صفحه به سرعت بارگذاری می‌شود و بدون هیچ نقصی کار می‌کند. با این حال در پشت صحنه، بدون نمایش هشدار دانلود یا درخواست دسترسی از سیستم‌عامل، کدهای جاوا اسکریپت اجراشده در آن برگه مرورگر به آرامی در حال استعلام از پنل مدیریت روتر وای‌فای خانگی، خواندن محتویات حافظه ذخیره‌سازی NAS یا ارسال دستور به تجهیزات هوشمند شبکه محلی شما هستند.

این یک سناریوی آزمایشی و خیالی نیست؛ این ماهیت عینی حمله تغییر نگاشت نام دامنه (DNS Rebinding) است. نفوذگران با بهره‌برداری از شکاف ساختاری میان سیستم تفکیک نام دامنه و مدل‌های امنیتی مرورگر، یک برگه عادی وب را به یک پراکسی نفوذ مستقیم به شبکه محلی خصوصی (LAN) تبدیل می‌کنند.

سازوکار فنی: عبور از مرز سیاست هم‌مبدأ Same-Origin

برای درک سازوکار DNS Rebinding، ابتدا باید ستون اصلی امنیت مرورگر را بررسی کرد: سیاست هم‌مبدأ (Same-Origin Policy یا SOP). این سیاست مقرر می‌دارد کدهایی که تحت یک مبدأ خاص (شامل پروتکل، دامنه و پورت مانند https://example.com:443) اجرا می‌شوند، مجاز به خواندن پاسخ‌های خام از مبدأ دیگری (نظیر http://192.168.1.1:80) نیستند. در حالت عادی، این سازوکار مانع از دسترسی وب‌سایت‌های مخرب به نشست‌های بانکی یا ابزارهای محلی می‌شود.

با این حال، سیاست هم‌مبدأ بر مبنای نام دامنه عمل می‌کند نه آدرس‌های عددی IP. وقتی مرورگر درخواستی به attacker-domain.com ارسال می‌کند، ابتدا از یک کارگزار بازگشتی DNS برای تبدیل نام دامنه به آدرس IP قابل مسیریابی استعلام می‌گیرد.

در حمله DNS Rebinding، مهاجم سرور نام دامنه اختصاصی خود را به شکلی پیکربندی می‌کند که پاسخی متغیر و مهندسی‌شده ارائه دهد:

۱. تفکیک اولیه با زمان حیات نزدیک به صفر: هنگام ورود به دامنه مهاجم، سرور DNS آدرس IP عمومی سرور خود را برمی‌گرداند که حاوی کدهای مخرب است. نکته اساسی این است که مقدار زمان حیات (Time-To-Live یا TTL) این رکورد روی صفر یا یک ثانیه تنظیم می‌شود تا از ذخیره پاسخ در حافظه کش مرورگر و سیستم جلوگیری شود.

۲. اجرای کدهای آلوده: مرورگر پرونده‌های HTML و جاوا اسکریپت را دریافت و اجرا می‌کند. این اسکریپت یک تایمر یا اتصال مداوم برقرار می‌سازد تا برگه مرورگر باز بماند.

۳. جابه‌جایی نگاشت آدرس: پس از چند ثانیه، هنگامی که کش کوتاه‌مدت سوکت‌های سیستم منقضی شد، اسکریپت درخواستی ثانویه به همان دامنه ارسال می‌کند: http://attacker-domain.com/api/settings.

۴. تغییر جهت به زیرشبکه خصوصی: از آنجا که زمان حیات اولیه به پایان رسیده، مرورگر ناچار است استعلام جدیدی بفرستد. این بار سرور DNS مهاجم پاسخی کاملاً متفاوت ارائه می‌دهد: به جای آدرس عمومی، آدرس IP خصوصی داخل شبکه قربانی را ارسال می‌کند — مانند 192.168.1.1 (درگاه روتر خانگی)، 127.0.0.1 (رابط لوپ‌بک سیستم) یا دستگاه‌های متصل به شبکه محلی.

۵. فریب سیاست هم‌مبدأ: از دید پشته شبکه مرورگر، مبدأ مقصد همچنان همان attacker-domain.com اولیه است. از آنجا که نام دامنه تغییر نکرده، سیاست هم‌مبدأ مانعی ایجاد نمی‌کند. مرورگر بسته HTTP را مستقیماً از طریق کارت شبکه فیزیکی به دستگاه محلی می‌فرستد، اطلاعات دریافتی را می‌خواند و آن را به سرور فرمان مهاجم مخابره می‌نماید.

اهداف آسیب‌پذیر: از مودم‌های خانگی تا محیط‌های برنامه‌نویسی

علت خطرات گسترده DNS Rebinding این است که تجهیزات شبکه داخلی معمولاً بر پایه اعتماد پیش‌فرض به زیرشبکه خصوصی RFC 1918 طراحی شده‌اند. به دلیل قرارگیری در پشت دیواره آتش و NAT، سازندگان اغلب تمهیدات احراز هویت را ساده انگاشته‌اند:

  • روترها و مودم‌های خانگی: بسیاری از روترها پنل وب خود را روی پورت‌های 80 یا 8080 بدون بررسی هدر Host و بدون محافظت در برابر جعل درخواست (CSRF) ارائه می‌دهند. کدهای مخرب می‌توانند کلید رمز عبور وای‌فای را استخراج کرده یا سرورهای DNS مودم را تغییر دهند.
  • تجهیزات اینترنت اشیاء و خانه هوشمند: دوربین‌های مداربسته تحت شبکه و کنترل‌کننده‌های روشنایی غالباً از رابط‌های REST فاقد رمز عبور استفاده می‌کنند. یک برگه مخرب می‌تواند وضعیت حسگرها را تغییر داده یا به تصاویر دوربین دسترسی یابد.
  • پورت‌های محیط توسعه نرم‌افزار: برنامه‌نویسان پایگاه‌های داده، ابزارهای کانتینر یا داشبوردهای اشکال‌زدایی را روی 127.0.0.1 بدون رمز عبور اجرا می‌کنند. یک صفحه وب باز می‌تواند به این پورت‌ها متصل شده و سورس‌کدها یا متغیرهای محرمانه را بخواند.

دفاع چندلایه: ایمن‌سازی کارگزارها، تجهیزات و تونل‌های شبکه

مهار حملات DNS Rebinding نیازمند هماهنگی جامع در لایه‌های تحلیل نام دامنه، اعتبارسنجی سرورهای محلی و کانال‌های ارتباطی امن است:

پالایش رکوردهای مشکوک در کارگزارهای محلی

کارآمدترین راهکار در سطح شبکه، فعال‌سازی سامانه مقابله با نگاشت مجدد (DNS rebind protection) در تحلیل‌کننده‌های محلی (مانند dnsmasq یا Unbound) است. این سامانه‌ها بسته‌های پاسخی دریافتی را بررسی می‌کنند؛ اگر دامنه‌ای عمومی پاسخی شامل آدرس‌های خصوصی RFC 1918 (10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16) یا آدرس لوپ‌بک (127.0.0.0/8) ارائه دهد، پاسخ فوراً رد شده و خطای NXDOMAIN صادر می‌گردد.

اعتبارسنجی هدر Host و استاندارد دسترسی به شبکه خصوصی

توسعه‌دهندگان باید بررسی دقیق هدر HTTP Host را الزامی کنند. هنگامی که اسکریپت ترافیک را به سمت روتر هدایت می‌کند، مرورگر مقدار هدر را با نام دامنه مهاجم ارسال می‌کند. سرور محلی باید هر درخواستی را که با localhost، 127.0.0.1 یا آدرس معتبر روتر مطابقت ندارد بلافاصله رد کند. علاوه بر این، مرورگرهای امروزی در حال پیاده‌سازی استاندارد دسترسی به شبکه خصوصی W3C (PNA) هستند که مانع ارسال درخواست‌های تاییدنشده از وب عمومی به منابع داخلی می‌شود.

جداسازی ترافیک با تونل رمزنگاری‌شده VPNRice

در شرایطی که به‌روزرسانی میان‌افزار تجهیزات قدیمی فرآیندی زمان‌بر است، استفاده از یک تونل رمزنگاری‌شده امنیتی فوری و ساختاری پدید می‌آورد.

استفاده از VPNRice ترافیک خروجی را در بستری ایزوله قرار می‌دهد. با بهره‌گیری از پروتکل‌های نوین RiceGuard و RiceGuardX در کنار الگوریتم‌های ChaCha20-Poly1305 و AES-256-GCM، تمام استعلام‌های نام دامنه از طریق کارگزارهای امن بدون نگهداری لاگ پردازش می‌شوند. تفکیک کامل ارتباطات از بستر محلی، امکان نفوذ و جعل مسیرهای تفکیک نام دامنه را از مهاجمان خارجی سلب می‌کند.

پیش از مراجعه به وب‌سایت‌های ناشناخته، می‌توانید مشخصات پیکربندی شبکه خود را با ابزار بررسی نشانی آی‌پی تحلیل کرده و عدم نشت آدرس‌های محلی را با سرویس آزمایش نشت WebRTC ارزیابی نمایید. تلفیق پالایش هوشمند DNS و شبکه رمزنگاری‌شده، اتصال شما را در برابر دسترسی‌های غیرمجاز ایمن می‌سازد.