DNS Rebinding چیست؟ بررسی حمله DNS Rebinding و روش‌های جلوگیری از آن

DNS Rebinding یک تکنیک حمله است که در آن مهاجم با کنترل پاسخ‌های DNS یک دامنه، مرورگر قربانی را وادار می‌کند همان دامنه را ابتدا به سرور مهاجم و سپس به یک IP داخلی، localhost یا سرویس موجود در شبکه خصوصی متصل کند. هدف اصلی این حمله دور زدن مرز میان اینترنت و شبکه داخلی و دسترسی از طریق مرورگر کاربر به سرویس‌هایی است که مستقیماً از اینترنت قابل دسترسی نیستند. استفاده از احراز هویت مناسب، اعتبارسنجی Host و Origin، محدودسازی دسترسی شبکه، محافظت DNS و مکانیزم‌های امنیتی مرورگر از مهم‌ترین روش‌های جلوگیری از DNS Rebinding هستند.

DNS یکی از اجزای اساسی اینترنت است. زمانی که کاربر آدرسی مانند example.com را وارد می‌کند، سیستم DNS وظیفه دارد نام دامنه را به IP قابل استفاده برای برقراری اتصال تبدیل کند. این فرایند در حالت عادی کاملاً طبیعی است؛ اما انعطاف‌پذیری DNS می‌تواند در شرایط خاص به بخشی از یک حمله امنیتی تبدیل شود.

یکی از تکنیک‌هایی که از همین ویژگی استفاده می‌کند، DNS Rebinding است.

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

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

به همین دلیل DNS Rebinding را نباید فقط یک مشکل مربوط به DNS دانست. این حمله در نقطه تلاقی چند فناوری اتفاق می‌افتد: DNS، مرورگر، Same-Origin Policy، شبکه داخلی، HTTP و نحوه طراحی سرویس‌های محلی.

در ادامه بررسی می‌کنیم DNS Rebinding چیست، چگونه عمل می‌کند، چه تفاوتی با DNS Spoofing، CSRF و SSRF دارد، چه سیستم‌هایی در معرض خطر بیشتری قرار دارند و مدیران سایت، توسعه‌دهندگان و مدیران شبکه چگونه می‌توانند احتمال موفقیت آن را کاهش دهند.

DNS Rebinding چیست؟

DNS Rebinding یا «اتصال مجدد DNS» تکنیکی است که در آن مهاجم دامنه و معمولاً زیرساخت DNS آن را کنترل می‌کند و پاسخ DNS دامنه را در طول زمان تغییر می‌دهد.

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

نکته کلیدی همین عبارت «همان hostname» است.

مرورگر برای تشخیص Origin صرفاً به IP مقصد نگاه نمی‌کند. Origin در وب بر اساس ترکیبی از پروتکل یا Scheme، نام میزبان و Port مشخص می‌شود. در نتیجه تغییر IP پشت یک hostname لزوماً به معنی تغییر Origin از دید مدل امنیتی وب نیست.

برای مثال فرض کنید کاربر صفحه‌ای با دامنه‌ای مانند زیر را باز کرده است:

http://example-attacker.test

مرورگر در ابتدا این دامنه را به یک سرور اینترنتی متصل می‌کند.

اگر در مرحله بعد همان دامنه از طریق DNS به یک IP خصوصی مانند یکی از دستگاه‌های شبکه محلی اشاره کند، نام دامنه موجود در URL همچنان تغییر نکرده است.

همین موضوع اساس DNS Rebinding را تشکیل می‌دهد.

البته مرورگرهای مدرن، DNS Cache، Connection Reuse، سیاست‌های مربوط به شبکه خصوصی و مکانیزم‌های دیگری دارند که اجرای حمله را نسبت به یک مدل ساده پیچیده‌تر می‌کنند. بنابراین هر تغییر رکورد DNS به معنای موفق شدن DNS Rebinding نیست.

با این حال اصل مشکل همچنان مهم است: نباید امنیت یک سرویس داخلی را صرفاً بر این فرض بنا کرد که کاربران اینترنت نمی‌توانند از داخل مرورگر خود به آن دسترسی داشته باشند.

چرا DNS Rebinding خطرناک است؟

در نگاه اول ممکن است گفته شود یک سرویس با IP خصوصی مثل 192.168.x.x از اینترنت قابل دسترسی نیست؛ پس چه خطری وجود دارد؟

این دیدگاه یک بخش مهم را نادیده می‌گیرد:

مرورگر قربانی خودش داخل شبکه خصوصی قرار دارد.

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

به همین دلیل DNS Rebinding در منابع امنیتی به‌عنوان روشی برای استفاده از مرورگر جهت تعامل با آدرس‌های داخلی توصیف می‌شود.

فرض کنید یک پنل مدیریتی فقط در شبکه داخلی در دسترس است:

192.168.1.10

از اینترنت عمومی دسترسی مستقیمی به این IP وجود ندارد.

اما لپ‌تاپ کاربر که هم به اینترنت و هم به شبکه 192.168.1.0/24 متصل است، احتمالاً می‌تواند به این دستگاه درخواست ارسال کند.

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

DNS Rebinding دقیقاً تلاش می‌کند از این اختلاف سطح دسترسی استفاده کند.

ارتباط DNS Rebinding با Same-Origin Policy چیست؟

برای درک DNS Rebinding باید ابتدا مفهوم Same-Origin Policy یا SOP را بشناسیم.

Same-Origin Policy یکی از مکانیزم‌های بنیادی امنیت مرورگرها است که دسترسی یک صفحه وب به منابع Originهای دیگر را محدود می‌کند.

Origin معمولاً از سه مؤلفه تشکیل می‌شود:

• Scheme مانند HTTP یا HTTPS
• Hostname
• Port

برای نمونه این دو URL می‌توانند Same-Origin باشند:

https://example.com/page1

https://example.com/page2

اما موارد زیر Origin متفاوتی دارند:

http://example.com

و:

https://example.com

زیرا Scheme متفاوت است.

همین موضوع درباره Port یا hostname متفاوت نیز صدق می‌کند.

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

مشکل از کجا شروع می‌شود؟

مسئله این است که IP آدرس جزئی از تعریف معمول Origin در URL نیست.

مرورگر ممکن است صفحه‌ای را از:

attacker-domain.example

دریافت کرده باشد.

این دامنه در ابتدا مثلاً به:

203.0.113.x

اشاره کرده است.

سپس DNS تغییر می‌کند و همان نام دامنه به یک مقصد خصوصی اشاره می‌کند.

از دید URL، hostname همچنان همان است.

این ویژگی یکی از پایه‌های نظری حمله DNS Rebinding است.

به بیان ساده، مهاجم تلاش می‌کند کاری کند که:

هویت منطقی مقصد در مرورگر ثابت بماند، اما مقصد واقعی شبکه تغییر کند.

البته مرورگرهای امروزی دفاع‌های دیگری نیز دارند و نباید این توضیح را به این معنا دانست که SOP در تمام مرورگرها به‌سادگی قابل دور زدن است. DNS Rebinding حمله‌ای وابسته به شرایط است و رفتار DNS Cache، اتصال‌های موجود، HTTPS، سیاست دسترسی به شبکه محلی و ویژگی‌های سرویس هدف همگی روی نتیجه اثر دارند.

حمله DNS Rebinding چگونه کار می‌کند؟

برای درک معماری حمله نیازی به اجرای نمونه مخرب نیست. می‌توان فرایند را به‌صورت مفهومی بررسی کرد.

مرحله اول: مهاجم یک دامنه در اختیار دارد

در یک سناریوی معمول، مهاجم باید بتواند پاسخ‌های DNS یک دامنه یا زیر دامنه را کنترل کند.

در ابتدا DNS دامنه به یک سرور عمومی متعلق به مهاجم اشاره می‌کند.

قربانی صفحه وب را باز کرده و محتوای آن از سرور اینترنتی دریافت می‌شود.

مرحله دوم: صفحه در مرورگر قربانی اجرا می‌شود

مرورگر دامنه را Resolve کرده و به IP اولیه متصل می‌شود.

از دید کاربر ممکن است یک صفحه کاملاً عادی نمایش داده شود.

در این مرحله Origin مربوط به دامنه مهاجم در مرورگر ایجاد شده است.

مرحله سوم: پاسخ DNS تغییر می‌کند

در ادامه، زیرساخت DNS تحت کنترل مهاجم می‌تواند پاسخ متفاوتی برای همان دامنه ارائه دهد.

برای مثال دامنه‌ای که قبلاً به یک IP عمومی اشاره می‌کرد، ممکن است بعداً به مقصدی در یکی از این محدوده‌ها اشاره کند:

127.0.0.0/8

یا شبکه‌های خصوصی IPv4 مانند:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

هدف می‌تواند localhost سیستم کاربر یا دستگاهی داخل LAN باشد.

مرحله چهارم: مرورگر Resolve جدید انجام می‌دهد

اگر شرایط DNS Cache، TTL، Connection Reuse و رفتار مرورگر اجازه دهد، ممکن است hostname دوباره Resolve شود.

این بار مقصد شبکه با مقصد اولیه متفاوت است.

مرحله پنجم: درخواست به سرویس داخلی می‌رسد

مرورگر همچنان از hostname موجود در URL استفاده می‌کند، اما اتصال شبکه ممکن است به IP داخلی برقرار شود.

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

مرحله ششم: سرویس داخلی تعیین‌کننده است

در این نقطه کیفیت امنیت سرویس هدف اهمیت زیادی پیدا می‌کند.

اگر سرویس:

• هر مقدار Host را بپذیرد؛
• احراز هویت مناسبی نداشته باشد؛
• عملیات حساس را بدون Authorization انجام دهد؛
• به درخواست‌های مرورگر اعتماد کند؛
• API مدیریتی خود را بدون محدودیت ارائه کند؛
• یا روی این فرض متکی باشد که «فقط localhost به من دسترسی دارد»؛

ریسک بیشتر خواهد شد.

بنابراین DNS Rebinding معمولاً از ترکیب چند ضعف یا فرض امنیتی نادرست بهره می‌برد، نه از یک مشکل واحد.

TTL چه نقشی در DNS Rebinding دارد؟

TTL یا Time To Live مشخص می‌کند پاسخ DNS چه مدت می‌تواند در Cache نگهداری شود.

از نظر تئوری، هرچه TTL کوتاه‌تر باشد، امکان Resolve مجدد دامنه در بازه زمانی کوتاه‌تری وجود دارد.

در توضیحات کلاسیک DNS Rebinding معمولاً از TTL پایین صحبت می‌شود، اما این موضوع نباید بیش از حد ساده‌سازی شود.

مرورگرها، سیستم‌عامل‌ها و DNS Resolverها الزاماً TTL را دقیقاً به همان شکل مورد انتظار یک مهاجم اجرا نمی‌کنند. بعضی مرورگرها Cache داخلی دارند، سیستم‌عامل ممکن است DNS Cache داشته باشد و اتصال HTTP موجود نیز ممکن است دوباره استفاده شود.

بنابراین نمی‌توان گفت:

«TTL صفر یا پایین مساوی با DNS Rebinding موفق است.»

TTL تنها یکی از عوامل مؤثر است.

چه سرویس‌هایی بیشتر در معرض DNS Rebinding هستند؟

DNS Rebinding زمانی ارزشمندتر می‌شود که مرورگر قربانی به منابعی دسترسی داشته باشد که خود مهاجم از اینترنت به آنها دسترسی ندارد.

چند دسته از سیستم‌ها معمولاً اهمیت بیشتری دارند.

روترها و تجهیزات شبکه

بسیاری از مودم‌ها، روترها، Access Pointها و تجهیزات شبکه دارای پنل مدیریتی تحت وب هستند.

این پنل‌ها معمولاً فقط روی شبکه داخلی فعال‌اند.

برای مثال رابط مدیریت ممکن است روی آدرسی مانند:

192.168.1.1

در دسترس باشد.

اگر سازنده صرفاً به خصوصی بودن IP اعتماد کرده باشد و کنترل‌های امنیتی مستقل نداشته باشد، DNS Rebinding می‌تواند یکی از تهدیدهای قابل بررسی باشد.

روتر باید حتی در شبکه داخلی نیز برای عملیات حساس احراز هویت واقعی انجام دهد.

دستگاه‌های IoT

دوربین‌ها، سیستم‌های خانه هوشمند، پرینترهای شبکه، دستگاه‌های ذخیره‌سازی، تجهیزات صوتی و بسیاری از محصولات IoT دارای رابط HTTP محلی هستند.

مشکل زمانی شدیدتر می‌شود که این سرویس‌ها:

• Password پیش‌فرض داشته باشند؛
• اصلاً Authentication نداشته باشند؛
• Firmware قدیمی داشته باشند؛
• Host Header را بررسی نکنند؛
• APIهای مدیریتی ناامن داشته باشند.

خصوصی بودن IP جایگزین احراز هویت نیست.

سرویس‌های localhost

توسعه‌دهندگان گاهی برنامه‌هایی را روی:

127.0.0.1

یا:

localhost

اجرا می‌کنند و تصور می‌کنند چون سرویس از اینترنت قابل دسترسی نیست، نیازی به مکانیزم‌های امنیتی ندارد.

این فرض همیشه مناسب نیست.

برخی ابزارهای توسعه، داشبوردها، APIها و نرم‌افزارهای دسکتاپ رابط HTTP محلی ایجاد می‌کنند.

اگر یک سرویس localhost قابلیت انجام عملیات حساس داشته باشد، باید فرض شود کدهای اجراشده در مرورگر ممکن است تلاش کنند به آن متصل شوند.

پنل‌های مدیریتی داخلی

سازمان‌ها ممکن است نرم‌افزارهایی داشته باشند که فقط از Intranet قابل دسترسی هستند.

DNS Rebinding نشان می‌دهد «قابل دسترسی نبودن مستقیم از اینترنت» نباید تنها لایه امنیتی این سرویس‌ها باشد.

Authentication، Authorization، کنترل Host و سایر مکانیزم‌ها همچنان ضروری‌اند.

محیط‌های توسعه و APIهای داخلی

Frameworkهای توسعه وب معمولاً یک Development Server ارائه می‌کنند.

اگر این سرویس دارای APIهایی برای Build، Debug، File Management، Hot Reload یا اجرای عملیات مدیریتی باشد، محافظت نکردن آن می‌تواند خطرناک باشد.

به همین دلیل بسیاری از Frameworkهای مدرن کنترل Host یا Trusted Hosts ارائه می‌کنند.

مهاجم در DNS Rebinding به چه چیزی دست پیدا می‌کند؟

تأثیر DNS Rebinding کاملاً به سرویس هدف بستگی دارد.

خود DNS Rebinding به‌تنهایی به معنی تصاحب کامل دستگاه نیست.

در یک سیستم خوب ایمن‌شده ممکن است درخواست به سرویس داخلی برسد، اما به دلیل Authentication یا Host Validation فوراً رد شود.

در مقابل، در یک سیستم ضعیف، پیامدهای احتمالی می‌توانند شامل موارد زیر باشند:

• تعامل غیرمجاز با API داخلی؛
• مشاهده برخی اطلاعات سرویس محلی؛
• تغییر تنظیمات دستگاه؛
• ارسال درخواست‌های مدیریتی؛
• شناسایی سرویس‌های داخلی؛
• دسترسی به رابط‌های فاقد Authentication؛
• استفاده از مرورگر قربانی برای برقراری ارتباط با شبکه خصوصی.

شدت خطر از یک سرویس به سرویس دیگر بسیار متفاوت است.

برای مثال یک صفحه وضعیت ساده که هیچ اطلاعات حساسی نمایش نمی‌دهد با یک API مدیریت روتر قابل مقایسه نیست.

آیا DNS Rebinding فقط شبکه LAN را هدف می‌گیرد؟

خیر.

اگرچه شبکه محلی یکی از شناخته‌شده‌ترین اهداف است، اما مفهوم DNS Rebinding می‌تواند سرویس‌های دیگری را نیز در بر گیرد.

localhost

آدرس‌های loopback مانند 127.0.0.1 از اهداف مهم هستند.

شبکه‌های خصوصی

محدوده‌های RFC1918 مانند 10.x.x.x، 172.16-31.x.x و 192.168.x.x می‌توانند در سناریوهای شبکه داخلی مطرح باشند.

IPv6

امنیت نباید فقط بر IPv4 متمرکز باشد. سرویس‌هایی که روی IPv6 listen می‌کنند نیز باید سیاست‌های دسترسی صحیح داشته باشند.

آدرس‌های Link-Local

برخی سیستم‌ها از آدرس‌های Link-Local برای سرویس‌های خاص استفاده می‌کنند.

قواعد Firewall و برنامه باید این فضاهای آدرس را نیز در مدل تهدید خود در نظر بگیرند.

DNS Rebinding چه تفاوتی با DNS Spoofing دارد؟

DNS Rebinding و DNS Spoofing هر دو با DNS ارتباط دارند، اما ماهیت آنها متفاوت است.

در DNS Spoofing یا DNS Cache Poisoning مهاجم سعی می‌کند پاسخ DNS جعلی را به قربانی یا Resolver تحمیل کند تا دامنه‌ای واقعی به مقصدی غیرمجاز هدایت شود.

برای مثال ممکن است کاربر قصد باز کردن یک وب‌سایت معتبر را داشته باشد، اما پاسخ DNS دستکاری شود.

در DNS Rebinding شرایط متفاوت است.

مهاجم معمولاً مالک یا کنترل‌کننده دامنه مورد استفاده در حمله است. یعنی لازم نیست رکورد DNS یک سایت معتبر را جعل کند.

او به‌صورت مشروع پاسخ‌های DNS دامنه خودش را تغییر می‌دهد تا مرورگر قربانی در زمان‌های مختلف به IPهای متفاوت هدایت شود.

بنابراین تفاوت بنیادی این است:

این دو حمله ممکن است هر دو از زیرساخت DNS استفاده کنند، اما نباید یکی در نظر گرفته شوند.

تفاوت DNS Rebinding با CSRF چیست؟

در CSRF یا Cross-Site Request Forgery، مهاجم قربانی را وادار می‌کند بدون قصد واقعی درخواست خاصی را به یک سرویس دیگر ارسال کند.

برای مثال اگر کاربر در یک پنل وارد شده باشد و آن پنل کنترل CSRF مناسبی نداشته باشد، یک سایت خارجی ممکن است بتواند یک درخواست تغییر وضعیت ایجاد کند.

اما در DNS Rebinding موضوع پیچیده‌تر است.

مهاجم تلاش می‌کند hostname تحت کنترل خودش را به مقصد داخلی متصل کند و از مدل Origin مرورگر بهره ببرد.

DNS Rebinding ممکن است در برخی سناریوها قابلیت‌هایی فراتر از CSRF ساده ایجاد کند؛ مخصوصاً زمانی که سرویس داخلی از دید مرورگر تحت hostname rebinding‌شده قابل تعامل شود.

با این حال دفاع‌های CSRF مانند CSRF Token و بررسی Origin همچنان می‌توانند تأثیر حملات مختلف مبتنی بر مرورگر را کاهش دهند.

تفاوت DNS Rebinding با SSRF چیست؟

SSRF یا Server-Side Request Forgery زمانی رخ می‌دهد که یک سرور درخواست شبکه را از طرف مهاجم ارسال کند.

در DNS Rebinding کلاسیک، نقش واسطه را عمدتاً مرورگر قربانی دارد.

برای مثال:

در SSRF:

مهاجم ← برنامه وب آسیب‌پذیر ← سرویس داخلی

در DNS Rebinding مرورگری:

مهاجم ← مرورگر قربانی ← سرویس داخلی

با این حال DNS Rebinding در دفاع SSRF نیز اهمیت دارد.

فرض کنید برنامه‌ای ابتدا دامنه ورودی کاربر را Resolve می‌کند، تأیید می‌کند که IP عمومی است و سپس در مرحله اتصال دوباره همان hostname را Resolve می‌کند.

اگر پاسخ DNS بین این دو مرحله تغییر کند، کنترل اولیه ممکن است بی‌اثر شود.

به همین دلیل در طراحی دفاع SSRF تنها Allowlist کردن نام دامنه کافی نیست. مقصد Resolve‌شده باید بررسی شود و اتصال واقعی نیز به همان مقصد تأییدشده برقرار شود تا یک Resolve مجدد کنترل‌نشده، بررسی امنیتی را دور نزند.

این حالت گاهی با مفهوم TOCTOU یا Time of Check to Time of Use نیز مرتبط می‌شود: چیزی هنگام بررسی امن بوده اما هنگام استفاده تغییر کرده است.

تفاوت DNS Rebinding با CORS Misconfiguration چیست؟

CORS تعیین می‌کند چه Originهایی اجازه دارند پاسخ منابع Cross-Origin را از طریق مرورگر بخوانند.

اشتباه در CORS می‌تواند اطلاعات حساس را در اختیار یک Origin غیرمجاز قرار دهد.

اما DNS Rebinding اساساً تلاش می‌کند شرایطی ایجاد کند که رابطه مقصد با Origin به شکل دیگری مورد سوءاستفاده قرار گیرد.

بنابراین تنظیم صحیح CORS مفید است، اما CORS به‌تنهایی راهکار کامل مقابله با DNS Rebinding نیست.

یک سرویس داخلی باید مستقل از CORS دارای:

Authentication،

Authorization،

Host Validation،

Origin Validation در محل مناسب،

و سیاست شبکه صحیح باشد.

چرا Host Header در جلوگیری از DNS Rebinding اهمیت زیادی دارد؟

یکی از مؤثرترین لایه‌های دفاعی در سرویس‌های HTTP، بررسی صحیح Host است.

فرض کنید سرویس داخلی فقط باید از طریق:

admin.internal.example

در دسترس باشد.

در یک سناریوی DNS Rebinding، URL مرورگر متعلق به دامنه مهاجم است. بنابراین درخواست HTTP نیز معمولاً Host مربوط به همان دامنه را خواهد داشت.

اگر سرور فقط Hostهای مورد انتظار خودش را قبول کند، می‌تواند درخواست را قبل از رسیدن به بخش حساس برنامه رد کند.

به همین دلیل سرویس نباید هر Host Header دلخواهی را بپذیرد.

سیاست مناسب Host Validation

بهتر است لیست دقیق hostnameهای معتبر تعریف شود.

برای مثال:

• localhost در صورت نیاز واقعی؛
• hostname داخلی رسمی برنامه؛
• نام دامنه مشخصی که برای سرویس تعریف شده است.

در مقابل سیاست‌هایی مانند:

«هر Host پذیرفته شود»

ریسک غیرضروری ایجاد می‌کنند.

پاسخ مناسب به Host نامعتبر

درخواست‌هایی که Host آنها در Allowlist قرار ندارد بهتر است پیش از پردازش اصلی با یک پاسخ خطا مانند 400 Bad Request یا 403 Forbidden متوقف شوند.

هدف این است که application logic حساس هرگز درخواست ناشناخته را پردازش نکند.

Trusted Hosts در Frameworkها

بسیاری از Frameworkهای وب امروزی امکانی برای تعریف Hostهای قابل اعتماد دارند.

نام این قابلیت بین Frameworkها متفاوت است؛ برای مثال ممکن است عباراتی مانند:

Allowed Hosts

Trusted Hosts

Host Authorization

یا تنظیمات مشابه مشاهده شود.

توسعه‌دهنده نباید این کنترل‌ها را صرفاً یک تنظیم اضافی یا مخصوص Production تلقی کند.

به‌خصوص اگر برنامه روی localhost، شبکه خصوصی یا محیط توسعه اجرا می‌شود، محدودسازی hostnameهای مجاز می‌تواند لایه دفاعی مؤثری در برابر DNS Rebinding باشد.

آیا HTTPS می‌تواند جلوی DNS Rebinding را بگیرد؟

HTTPS مانع مطلق DNS Rebinding نیست، اما می‌تواند مانع مهمی ایجاد کند.

در TLS، مرورگر انتظار دارد گواهی ارائه‌شده توسط سرور با hostname موجود در URL سازگار باشد.

فرض کنید کاربر صفحه زیر را باز کرده باشد:

https://attacker.example

و DNS بعداً به یک سرور داخلی هدایت شود.

سرور داخلی معمولاً گواهی معتبر برای attacker.example ندارد.

در نتیجه TLS Validation باید اتصال را رد کند.

این یکی از مزیت‌های مهم استفاده صحیح از HTTPS است.

اما نباید HTTPS را تنها راهکار دفاعی دانست.

محیط‌های توسعه، دستگاه‌های IoT و بسیاری از پنل‌های داخلی همچنان از HTTP استفاده می‌کنند یا ممکن است تنظیمات TLS ضعیفی داشته باشند.

همچنین مدل تهدید هر معماری متفاوت است.

دفاع اصولی باید چندلایه باشد.

نقش Authentication در مقابله با DNS Rebinding

یکی از مهم‌ترین اشتباهات طراحی این است که توسعه‌دهنده تصور کند:

«چون سرویس فقط روی LAN یا localhost قابل دسترسی است، دیگر Password یا Authentication لازم نیست.»

این فرض در مدل امنیتی مدرن مناسب نیست.

شبکه خصوصی لزوماً یک Trust Boundary کافی محسوب نمی‌شود.

اگر API قابلیت انجام عملیات حساس دارد، باید Authentication واقعی داشته باشد.

برای مثال API مدیریت دستگاه نباید صرفاً به این دلیل که درخواست از یک IP داخلی آمده است، آن را معتبر تصور کند.

Authentication مناسب می‌تواند شامل:

• Session امن؛
• Token غیرقابل حدس؛
• API Key با مدیریت صحیح؛
• Client Certificate در محیط‌های مناسب؛
• یا مکانیزم استاندارد هویت سازمانی

باشد.

مکانیزم انتخابی به نوع سرویس بستگی دارد.

Authorization را فراموش نکنید

Authentication مشخص می‌کند کاربر چه کسی است.

Authorization مشخص می‌کند آن کاربر چه کاری اجازه دارد انجام دهد.

حتی اگر DNS Rebinding نتواند Authentication را دور بزند، ضعف Authorization ممکن است همچنان مشکل ایجاد کند.

برای مثال یک Endpoint نباید فقط به دلیل اینکه درخواست احراز هویت شده است اجازه تغییر تمام تنظیمات مدیریتی را بدهد.

اصل Least Privilege باید اعمال شود.

هر Endpoint فقط حداقل دسترسی موردنیاز را ارائه کند.

بررسی Origin چگونه کمک می‌کند؟

Header مربوط به Origin در بسیاری از درخواست‌های مرورگر اطلاعاتی درباره مبدأ درخواست فراهم می‌کند.

برای عملیات حساس، بررسی Server-Side Origin می‌تواند یک لایه دفاعی مفید باشد.

سرویس باید فقط Originهای شناخته‌شده و مورد انتظار را قبول کند.

استفاده از:

Access-Control-Allow-Origin: *

در یک API حساس بدون بررسی معماری امنیتی می‌تواند خطرناک باشد.

درخواست‌هایی که Origin غیرمنتظره دارند باید در صورت امکان رد شوند.

البته Origin Validation نیز نباید تنها خط دفاع باشد.

هدف معماری امن، ایجاد چند لایه مستقل است.

CSRF Token همچنان اهمیت دارد

اگر سرویس مبتنی بر Cookie و Session است و عملیات تغییردهنده وضعیت دارد، CSRF Protection باید فعال باشد.

یک CSRF Token مناسب باید:

• غیرقابل حدس باشد؛
• به Session مرتبط باشد؛
• در عملیات حساس بررسی شود؛
• از مکانیزم استاندارد Framework استفاده کند.

این کنترل علاوه بر DNS Rebinding، در مقابل دسته بزرگ‌تری از حملات Cross-Site نیز سودمند است.

آیا Firewall جلوی DNS Rebinding را می‌گیرد؟

Firewall می‌تواند بخشی از دفاع باشد، اما پاسخ کاملاً به معماری بستگی دارد.

اگر یک سرویس برای استفاده توسط کاربران همان شبکه طراحی شده باشد، Firewall طبیعتاً باید اجازه دسترسی از LAN را بدهد.

مرورگر قربانی نیز داخل همان LAN قرار دارد.

در چنین شرایطی Firewall نمی‌تواند تشخیص دهد درخواست از تصمیم مستقیم کاربر آمده یا توسط JavaScript یک صفحه وب ایجاد شده است.

بنابراین Firewall به‌تنهایی کافی نیست.

با این حال Network Segmentation می‌تواند دامنه تأثیر حمله را کاهش دهد.

برای مثال قرار دادن تجهیزات مدیریتی حساس در VLAN جداگانه و محدودسازی دسترسی به آنها می‌تواند بسیار مؤثر باشد.

DNS Rebinding Protection در DNS Resolver چیست؟

برخی DNS Resolverها و تجهیزات شبکه دارای قابلیتی با عنوان‌هایی مانند:

DNS Rebind Protection

هستند.

هدف این قابلیت معمولاً شناسایی شرایطی است که یک دامنه اینترنتی ناگهان به IP خصوصی یا loopback Resolve می‌شود.

Resolver می‌تواند چنین پاسخ‌هایی را رد یا فیلتر کند.

این قابلیت لایه دفاعی ارزشمندی است، به‌خصوص در شبکه‌های سازمانی و خانگی.

با این حال محدودیت‌هایی دارد.

ممکن است سازمان به‌صورت مشروع دامنه‌هایی داشته باشد که به IP داخلی Resolve می‌شوند. این معماری که گاهی در قالب Split DNS یا Split-Horizon DNS دیده می‌شود نباید با یک حمله اشتباه گرفته شود.

به همین دلیل DNS Rebind Protection ممکن است به Allowlist و تنظیم دقیق نیاز داشته باشد.

Split DNS با DNS Rebinding تفاوت دارد

در Split DNS ممکن است یک hostname بسته به اینکه درخواست از داخل یا خارج سازمان ارسال شده، پاسخ متفاوتی داشته باشد.

این یک معماری مشروع است.

مثلاً:

portal.example.com

از اینترنت به یک IP عمومی و از شبکه داخلی به IP خصوصی اشاره کند.

این رفتار به‌تنهایی DNS Rebinding محسوب نمی‌شود.

تفاوت اصلی در هدف، کنترل و نحوه استفاده از تغییر پاسخ است.

DNS Rebinding یک تکنیک حمله برای سوءاستفاده از تغییر مقصد شبکه در بستر یک hostname است، در حالی که Split DNS یک طراحی معمول شبکه است.

Local Network Access در مرورگرهای جدید

مرورگرها نیز در سال‌های اخیر دفاع‌های بیشتری برای ارتباط صفحات اینترنتی با شبکه محلی ایجاد کرده‌اند.

یکی از مهم‌ترین تحولات، محدودسازی درخواست‌هایی است که از یک سایت عمومی به منابع موجود در شبکه محلی یا loopback ارسال می‌شوند.

Chrome رویکرد Local Network Access یا LNA را برای این منظور توسعه داده است. در Chrome 142 دسترسی سایت‌ها به شبکه محلی پشت یک Permission قرار گرفت تا کاربر برای چنین دسترسی‌ای اجازه بدهد. هدف این سیاست کاهش حملاتی مانند CSRF علیه روترها و دستگاه‌های داخلی و محدود کردن دسترسی ناخواسته وب‌سایت‌ها به شبکه محلی است.

این تغییرات امنیت مرورگر بسیار مفید هستند، اما مدیر یک سرویس نباید امنیت محصول خود را وابسته به وجود یک مرورگر، یک نسخه یا یک سیاست خاص کند.

دفاع سمت سرور همچنان ضروری است.

چرا نباید فقط به دفاع مرورگر اعتماد کرد؟

سه دلیل اصلی وجود دارد.

تفاوت مرورگرها

تمام مرورگرها دقیقاً یک رفتار، نسخه یا زمان‌بندی یکسان برای قابلیت‌های امنیتی ندارند.

نسخه‌های قدیمی

کاربران ممکن است از Browser یا سیستم‌عامل قدیمی استفاده کنند.

WebView و Clientهای دیگر

درخواست همیشه از Chrome یا Firefox دسکتاپ ارسال نمی‌شود.

برنامه‌های مبتنی بر WebView، Embedded Browserها و Clientهای دیگر ممکن است رفتار متفاوتی داشته باشند.

بنابراین قاعده مناسب این است:

دفاع مرورگر یک لایه اضافه است، نه جایگزین امنیت سرویس.

جلوگیری از DNS Rebinding در سرویس‌های localhost

اگر نرم‌افزاری یک HTTP Server محلی ایجاد می‌کند، چند اصل باید رعایت شود.

سرویس غیرضروری ایجاد نکنید

اگر برنامه نیازی به HTTP Server ندارد، ایجاد یک Listener محلی سطح حمله را افزایش می‌دهد.

در بعضی معماری‌ها استفاده از IPC، Unix Domain Socket یا مکانیزم‌های داخلی سیستم‌عامل انتخاب مناسب‌تری است.

Host را بررسی کنید

اگر سرویس فقط با hostnameهای خاص کار می‌کند، درخواست سایر Hostها را رد کنید.

عملیات حساس را بدون احراز هویت اجرا نکنید

یک Token تصادفی یا مکانیزم هویت مناسب می‌تواند امنیت را به شکل محسوسی افزایش دهد.

API را حداقل نگه دارید

هر Endpoint اضافی سطح حمله جدیدی ایجاد می‌کند.

تنها قابلیت‌هایی را در API محلی قرار دهید که واقعاً موردنیاز هستند.

دسترسی‌های برنامه را محدود کنید

اگر سرویس compromise شود، نباید به‌طور پیش‌فرض دسترسی Administrator یا root داشته باشد.

Least Privilege همچنان اهمیت دارد.

جلوگیری از DNS Rebinding در روتر و تجهیزات IoT

سازندگان تجهیزات شبکه باید DNS Rebinding را در Threat Model محصول در نظر بگیرند.

صرف اینکه پنل روی 192.168.1.1 قرار دارد کافی نیست.

یک پنل مدیریت امن بهتر است:

احراز هویت اجباری داشته باشد.

Password پیش‌فرض مشترک نداشته باشد.

Host Header را اعتبارسنجی کند.

برای عملیات حساس از CSRF Protection استفاده کند.

Originهای غیرمنتظره را بررسی کند.

Session امن داشته باشد.

Firmware آن قابلیت دریافت Update امنیتی داشته باشد.

قابلیت‌های مدیریتی غیرضروری غیرفعال باشند.

اگر HTTPS عملی است، ارتباط مدیریتی رمزگذاری شود.

دسترسی مدیریتی از Interfaceهای غیرضروری مسدود باشد.

این موارد فقط برای DNS Rebinding نیستند؛ مجموعه آنها سطح حمله دستگاه را در برابر تهدیدهای متعدد کاهش می‌دهد.

جلوگیری از DNS Rebinding در برنامه‌های وب

اگر برنامه‌ای در شبکه داخلی اجرا می‌شود، باید همان اصول یک برنامه اینترنتی جدی در آن رعایت شود.

Host Allowlist

به‌جای قبول تمام Hostها، نام‌های معتبر را مشخص کنید.

Authentication

هیچ Endpoint حساس نباید صرفاً به اعتماد شبکه متکی باشد.

Authorization

برای هر عملیات سطح دسترسی بررسی شود.

CSRF Protection

در برنامه‌های Session-Based فعال باشد.

Origin Validation

برای Endpointهای حساس و سناریوهایی که قابل استفاده است اعمال شود.

HTTPS

تا حد امکان ارتباط رمزگذاری و هویت سرور با TLS تأیید شود.

Network Segmentation

برنامه‌های مدیریتی حیاتی در همان Segment عمومی کاربران قرار نگیرند.

Logging

درخواست‌های غیرعادی ثبت شوند تا امکان تشخیص و Incident Response وجود داشته باشد.

جلوگیری از DNS Rebinding در Reverse Proxy

Reverse Proxy می‌تواند محل مناسبی برای اجرای برخی کنترل‌های اولیه باشد.

برای مثال Proxy می‌تواند درخواست‌هایی را که Host آنها با دامنه‌های تعریف‌شده مطابقت ندارد، قبل از رسیدن به Backend رد کند.

این معماری دو مزیت دارد:

اول اینکه کنترل در یک نقطه مرکزی انجام می‌شود.

دوم اینکه Backend حتی درخواست نامعتبر را دریافت نمی‌کند.

با این حال برنامه اصلی نیز در صورت امکان باید Validation خودش را داشته باشد.

اصل Defense in Depth می‌گوید امنیت بهتر است به یک کنترل واحد وابسته نباشد.

نقش DNS Server سازمانی

سازمان‌هایی که DNS Resolver داخلی مدیریت می‌کنند می‌توانند Policyهایی برای شناسایی پاسخ‌های مشکوک داشته باشند.

برای مثال دامنه‌های اینترنتی ناشناخته که دائماً بین IP عمومی و خصوصی تغییر می‌کنند می‌توانند ارزش بررسی داشته باشند.

اما استفاده صرف از TTL پایین به‌عنوان Indicator حمله مناسب نیست.

بسیاری از CDNها، سرویس‌های ابری و زیرساخت‌های Dynamic DNS رفتارهای کاملاً مشروعی دارند.

تشخیص باید بر اساس مجموعه‌ای از Signalها انجام شود.

نشانه‌های احتمالی DNS Rebinding

تشخیص DNS Rebinding همیشه ساده نیست، اما برخی رفتارها می‌توانند ارزش بررسی داشته باشند.

برای مثال:

یک دامنه عمومی در فاصله زمانی کوتاه به Public IP و سپس Private IP Resolve شود.

دامنه ناشناخته به loopback Resolve شود.

درخواست HTTP به یک سرویس داخلی با Host خارجی و غیرمنتظره دریافت شود.

یک API داخلی تعداد زیادی درخواست از Browser Client دریافت کند.

درخواست‌های Origin ناشناخته به سرویس مدیریتی مشاهده شوند.

DNS Resolver رویداد مربوط به Rebind Protection ثبت کند.

تجهیزات داخلی درخواست‌هایی با Hostname اینترنتی دریافت کنند.

هیچ‌کدام از این موارد به تنهایی اثبات حمله نیستند، اما برای بررسی امنیتی مفیدند.

Logging مناسب چه کمکی می‌کند؟

یکی از دلایلی که حملات به سرویس‌های داخلی دیر تشخیص داده می‌شوند، Logging ضعیف است.

برای سرویس‌های حساس بهتر است حداقل اطلاعات لازم مانند موارد زیر ثبت شود:

زمان درخواست،

IP Client،

Hostname یا Host Header،

Origin در صورت وجود،

Endpoint،

HTTP Method،

کد پاسخ،

نتیجه Authentication،

و رویدادهای مهم Authorization.

البته Log نباید Password، Token، Cookie یا سایر اسرار حساس را بدون ضرورت ذخیره کند.

هدف، فراهم کردن داده کافی برای تشخیص رفتار غیرعادی بدون ایجاد یک مخزن جدید از اطلاعات حساس است.

DNS Rebinding در تست امنیت سایت چگونه بررسی می‌شود؟

تست DNS Rebinding باید فقط روی سیستمی انجام شود که مجوز صریح بررسی آن وجود دارد.

برای ارزیابی دفاعی نیازی نیست مستقیماً یک حمله کامل ساخته شود.

می‌توان ابتدا معماری را بررسی کرد.

بررسی سرویس‌های داخلی

مشخص کنید چه HTTP Serviceهایی روی:

localhost،

LAN،

شبکه مدیریت،

و محیط Development

فعال هستند.

بررسی Authentication

هر سرویس حساس باید مستقل از محل شبکه Authentication داشته باشد.

بررسی Host Validation

با یک درخواست کنترل‌شده در محیط آزمایش می‌توان بررسی کرد که آیا سرور Hostهای ناشناخته را رد می‌کند یا خیر.

برای نمونه مدیر همان سیستم می‌تواند روی محیط تست خودش بررسی کند که درخواست با Host غیرمجاز به پاسخ 400 یا 403 منجر می‌شود.

هدف این آزمایش حمله نیست؛ هدف اثبات فعال بودن کنترل دفاعی است.

بررسی DNS Resolver

بررسی کنید Router یا DNS Resolver سازمان قابلیت DNS Rebind Protection دارد یا خیر.

بررسی Browser Policy

در محیط‌های Enterprise می‌توان سیاست‌های Browser را نیز به‌عنوان لایه مکمل بررسی کرد.

بررسی TLS

اگر سرویس مدیریتی از HTTPS استفاده می‌کند، وضعیت Certificate Validation نیز باید ارزیابی شود.

چک‌لیست جلوگیری از DNS Rebinding

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

در سطح برنامه

• Hostهای مجاز مشخص شده‌اند.
• Host ناشناخته رد می‌شود.
• Authentication برای عملیات حساس فعال است.
• Authorization برای هر عملیات بررسی می‌شود.
• CSRF Protection در محل مناسب فعال است.
• Originهای حساس بررسی می‌شوند.
• CORS بیش از حد باز نیست.
• API غیرضروری وجود ندارد.
• Error Message اطلاعات داخلی بیش از حد فاش نمی‌کند.

در سطح شبکه

• سرویس مدیریتی در Segment مناسب قرار دارد.
• Firewall دسترسی غیرضروری را مسدود می‌کند.
• DNS Rebind Protection بررسی شده است.
• سرویس‌های حساس مستقیماً برای تمام LAN قابل دسترسی نیستند.
• IPv4 و IPv6 هر دو در Policy لحاظ شده‌اند.

در سطح ارتباط

• HTTPS در صورت امکان فعال است.
• Certificate Validation صحیح است.
• HTTP ناامن بدون ضرورت استفاده نمی‌شود.

در سطح سیستم

• سرویس با حداقل دسترسی اجرا می‌شود.
• Update امنیتی نصب می‌شود.
• سرویس‌های غیرضروری غیرفعال‌اند.
• Portهای غیرضروری باز نیستند.

در سطح مانیتورینگ

• Host Headerهای غیرعادی Log می‌شوند.
• خطاهای Authentication قابل مانیتور هستند.
• DNSهای غیرعادی بررسی می‌شوند.
• رویدادهای مدیریتی Audit Log دارند.

وجود همه این کنترل‌ها بسته به نوع سیستم ضروری نیست، اما هر سرویس حساس باید Threat Model مشخصی داشته باشد.

اشتباهات رایج در مقابله با DNS Rebinding

اعتماد کامل به Private IP

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

«IP خصوصی است، پس امن است.»

Private IP فقط دسترسی مستقیم از اینترنت را محدود می‌کند.

مرورگر، سیستم آلوده، دستگاه دیگر LAN یا کاربر داخلی همچنان می‌تواند به آن دسترسی داشته باشد.

اعتماد کامل به localhost

127.0.0.1 یک مرز امنیتی مطلق برای سرویس HTTP نیست.

برنامه‌های مختلف روی سیستم و در برخی شرایط محتوای اجراشده توسط Browser ممکن است بتوانند به Listener محلی درخواست ایجاد کنند.

اتکا به CORS

CORS یک مکانیزم مهم است، اما برای حل تمام مشکلات DNS Rebinding طراحی نشده است.

اتکا به Firewall

Firewall نمی‌تواند همیشه تفاوت بین درخواست واقعی کاربر و درخواست ایجادشده توسط مرورگر او را تشخیص دهد.

غیرفعال کردن Authentication در محیط Development

محیط توسعه اغلب اطلاعات و قابلیت‌های قدرتمندی دارد.

Development Server نباید صرفاً به دلیل داخلی بودن کاملاً بدون محافظ باشد.

Allow کردن هر Host

پذیرفتن تمام Host Headerها یکی از تنظیماتی است که باید به‌ویژه در سرویس‌های محلی و مدیریتی مورد بازبینی قرار گیرد.

اعتماد کامل به مرورگرهای جدید

وجود مکانیزم‌هایی مانند Local Network Access به معنی بی‌نیازی سرور از کنترل‌های امنیتی نیست.

بررسی فقط IPv4

اگر برنامه روی IPv6 نیز Listen می‌کند، Policyهای امنیتی باید هر دو Protocol Family را پوشش دهند.

استفاده از DNS Allowlist بدون بررسی IP واقعی

این مشکل مخصوصاً در URL Fetcherها و دفاع SSRF مهم است.

اگر برنامه فقط نام دامنه را بررسی کند اما مقصد Resolve‌شده و IP اتصال واقعی را کنترل نکند، تغییر DNS می‌تواند Policy را تضعیف کند.

DNS Rebinding و امنیت WordPress

یک سایت WordPress عمومی معمولاً سناریوی کلاسیک هدف DNS Rebinding نیست، زیرا از قبل روی اینترنت منتشر شده است.

با این حال اکوسیستم WordPress می‌تواند در چند حالت با این موضوع ارتباط پیدا کند.

محیط توسعه محلی وردپرس

ابزارهای Local Development ممکن است سرویس‌های مدیریتی، Database UI، Mail Testing یا APIهای جانبی روی localhost ایجاد کنند.

این سرویس‌ها باید جداگانه امن شوند.

افزونه‌هایی که URL دریافت می‌کنند

اگر افزونه یا سرویس WordPress از URL ارائه‌شده توسط کاربر داده دریافت می‌کند، مسئله اصلی معمولاً SSRF است؛ اما تغییر پاسخ DNS می‌تواند بررسی‌های ضعیف مبتنی بر hostname را دور بزند.

در چنین شرایطی باید تمام IPهای Resolve‌شده بررسی شوند و اتصال فقط به مقصد تأییدشده انجام شود.

داشبوردهای داخلی

اگر WordPress یا ابزار مرتبط فقط داخل یک سازمان در دسترس است، نباید Private Network بودن جایگزین Authentication شود.

REST API سفارشی

Endpointهای سفارشی باید Permission Callback، Authentication و Authorization مناسب داشته باشند.

در نتیجه مدیر سایت باید DNS Rebinding را بخشی از Threat Model کلی سرویس‌های داخلی و ابزارهای پیرامون WordPress بداند، نه صرفاً یک «آسیب‌پذیری وردپرس».

ارتباط DNS Rebinding با SSRF Protection

یکی از جاهایی که DNS Rebinding از حوزه مرورگر فراتر می‌رود، سیستم‌هایی هستند که URL دریافت و از سمت Server آنها را Fetch می‌کنند.

فرض کنید Backend ابتدا hostname را Resolve کند.

IP برابر یک Public IP باشد.

سیستم نتیجه بگیرد مقصد امن است.

چند لحظه بعد HTTP Client دوباره hostname را Resolve کند.

اگر DNS اکنون به Private IP اشاره کند، Validation اولیه دیگر تضمین‌کننده مقصد اتصال نیست.

برای جلوگیری از این مسئله بهتر است:

تمام رکوردهای A و AAAA بررسی شوند.

Private، Loopback، Link-Local و سایر محدوده‌های غیرمجاز رد شوند.

Redirect دوباره تحت همان Policy بررسی شود.

اتصال به IP تأییدشده Bind شود.

Hostname اصلی برای TLS/SNI و Host در صورت نیاز حفظ شود.

Retryها نیز همان Policy امنیتی را رعایت کنند.

این طراحی جلوی دسته‌ای از Bypassهای مبتنی بر تغییر DNS را می‌گیرد.

آیا DNSSEC جلوی DNS Rebinding را می‌گیرد؟

خیر، حداقل نه در سناریوی کلاسیک DNS Rebinding.

DNSSEC برای تضمین اصالت و Integrity داده DNS طراحی شده است و می‌تواند در برابر جعل برخی پاسخ‌های DNS مفید باشد.

اما در DNS Rebinding مهاجم معمولاً مالک دامنه خودش است و رکوردهای همان دامنه را عمداً تغییر می‌دهد.

در چنین شرایطی پاسخ DNS می‌تواند از نظر DNSSEC کاملاً معتبر باشد و در عین حال برای Rebinding استفاده شود.

بنابراین DNSSEC راهکار مستقیمی برای این حمله نیست.

این نکته تفاوت DNS Rebinding و DNS Cache Poisoning را دوباره نشان می‌دهد.

آیا استفاده از TTL طولانی مشکل را حل می‌کند؟

TTL بلند می‌تواند بعضی شکل‌های Rebinding را دشوارتر کند، اما یک دفاع قابل اتکا برای سرویس هدف محسوب نمی‌شود.

مدیر یک سرویس داخلی کنترلی روی TTL دامنه مهاجم ندارد.

علاوه بر آن Browser، Resolver و سیستم‌عامل هر کدام رفتار Cache خاص خود را دارند.

بنابراین امنیت باید در خود سرویس و شبکه اعمال شود.

آیا بستن JavaScript راهکار محسوب می‌شود؟

بسیاری از سناریوهای DNS Rebinding وب از JavaScript برای ایجاد تعاملات بعدی استفاده می‌کنند، اما انتظار اینکه کاربران JavaScript را کاملاً غیرفعال کنند راهکار عملی برای امنیت یک سرویس نیست.

دفاع باید در سمت سرویس انجام شود.

یک سرویس امن نباید به تنظیمات شخصی Browser کاربر وابسته باشد.

نقش Zero Trust در کاهش خطر DNS Rebinding

اصل مهم Zero Trust این است که محل شبکه به‌تنهایی نباید معیار اعتماد باشد.

این دیدگاه کاملاً با دفاع در برابر DNS Rebinding همخوانی دارد.

در معماری سنتی ممکن است فرض شود:

داخل LAN = قابل اعتماد

بیرون LAN = غیرقابل اعتماد

اما تهدیدهایی مانند DNS Rebinding، سیستم آلوده، Insider Threat و دستگاه‌های شخصی نشان می‌دهند این مرز همیشه کافی نیست.

در مدل Zero Trust، هر درخواست براساس:

هویت،

مجوز،

Context،

دستگاه،

سرویس،

و Policy

ارزیابی می‌شود.

در نتیجه حتی اگر درخواست از شبکه داخلی آمده باشد، برای عملیات حساس Authentication و Authorization همچنان ضروری هستند.

راهکار پیشنهادی برای سازمان‌ها

در یک سازمان متوسط یا بزرگ، مقابله با DNS Rebinding بهتر است به‌صورت چندلایه اجرا شود.

لایه اول، Asset Discovery است.

سازمان باید بداند چه سرویس‌های HTTP داخلی فعال هستند.

لایه دوم، Application Security است.

Host Validation، Authentication، Authorization و CSRF Protection باید بررسی شوند.

لایه سوم، Network Security است.

سرویس‌های مدیریتی باید Segment شوند و دسترسی آنها محدود باشد.

لایه چهارم، DNS Security است.

Resolver سازمانی می‌تواند قابلیت Rebind Protection و Monitoring داشته باشد.

لایه پنجم، Endpoint و Browser Security است.

Browserهای به‌روز و Policyهای مناسب استفاده شوند.

لایه ششم، Monitoring است.

DNS Log، Reverse Proxy Log و Audit Log سرویس‌های حساس باید قابل تحلیل باشند.

این رویکرد بسیار قابل اعتمادتر از تکیه بر یک مکانیزم واحد است.

اگر به DNS Rebinding مشکوک شدیم چه کنیم؟

اگر شواهدی از حمله مشاهده شد، اولین کار تعیین محدوده حادثه است.

باید مشخص شود:

کدام دامنه درگیر بوده است؟

دامنه به چه IPهایی Resolve شده؟

کدام کاربران آن را باز کرده‌اند؟

چه سرویس‌های داخلی درخواست دریافت کرده‌اند؟

آیا عملیات حساس انجام شده است؟

آیا Authentication دور زده شده؟

آیا اطلاعاتی افشا شده است؟

پس از آن می‌توان اقدامات مهار را انجام داد.

دامنه مشکوک در DNS یا Secure Web Gateway مسدود شود.

Sessionهای حساس در صورت نیاز باطل شوند.

Credentialهای مرتبط در صورت احتمال افشا تعویض شوند.

سرویس داخلی اصلاح شود.

Host Validation فعال شود.

Logها برای فعالیت‌های مشابه بررسی شوند.

Firmware تجهیزات شبکه و IoT به‌روزرسانی شود.

DNS Rebind Protection در صورت امکان فعال گردد.

نکته مهم این است که فقط مسدود کردن دامنه مهاجم مشکل اصلی را حل نمی‌کند.

اگر سرویس داخلی همچنان هر Host را بپذیرد و Authentication نداشته باشد، مهاجم دیگری ممکن است همان ضعف معماری را دوباره هدف بگیرد.

یک معماری مقاوم در برابر DNS Rebinding چگونه است؟

فرض کنیم سازمان یک Dashboard مدیریتی داخلی دارد.

معماری ضعیف ممکن است چنین باشد:

Dashboard روی HTTP اجرا می‌شود.

تمام Hostها را قبول می‌کند.

هیچ Authentication ندارد.

تمام کاربران LAN به آن دسترسی دارند.

عملیات حساس با درخواست ساده اجرا می‌شود.

در مقابل معماری امن‌تر می‌تواند چنین باشد:

Dashboard فقط روی Segment مدیریتی در دسترس است.

HTTPS معتبر دارد.

Hostname مشخصی برای آن تعریف شده است.

Reverse Proxy سایر Hostها را رد می‌کند.

کاربر باید Authentication انجام دهد.

Authorization مبتنی بر Role فعال است.

عملیات تغییردهنده وضعیت دارای CSRF Protection هستند.

Originهای غیرمجاز رد می‌شوند.

تمام تغییرات مدیریتی Audit Log دارند.

در این معماری حتی اگر یک لایه شکست بخورد، مهاجم با لایه‌های بعدی مواجه می‌شود.

این همان مفهوم Defense in Depth است.

DNS Rebinding چقدر خطرناک است؟

برای DNS Rebinding نمی‌توان یک سطح خطر ثابت برای تمام سیستم‌ها تعیین کرد.

شدت ریسک به چند سؤال بستگی دارد:

آیا سرویس‌های داخلی حساس وجود دارند؟

آیا Browser کاربر می‌تواند به آنها دسترسی داشته باشد؟

آیا Host Validation فعال است؟

آیا Authentication وجود دارد؟

آیا عملیات حساس بدون Authorization انجام می‌شوند؟

آیا سرویس از HTTP استفاده می‌کند؟

آیا DNS Rebind Protection وجود دارد؟

آیا مرورگر دسترسی به شبکه محلی را محدود می‌کند؟

آیا سیستم دارای Network Segmentation است؟

اگر چند کنترل امنیتی مستقل وجود داشته باشد، احتمال تبدیل DNS Rebinding به یک رخنه جدی بسیار کمتر می‌شود.

اما اگر امنیت سرویس فقط بر عبارت «از اینترنت قابل دسترسی نیست» بنا شده باشد، موضوع ارزش بررسی فوری دارد.

سؤالات متداول درباره DNS Rebinding

DNS Rebinding چیست؟

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

آیا DNS Rebinding همان DNS Spoofing است؟

خیر. در DNS Spoofing معمولاً مهاجم پاسخ DNS یک دامنه دیگر را جعل یا Poison می‌کند. در DNS Rebinding مهاجم غالباً دامنه خودش را کنترل کرده و رکوردهای آن را به‌صورت برنامه‌ریزی‌شده تغییر می‌دهد.

آیا DNSSEC جلوی DNS Rebinding را می‌گیرد؟

خیر. اگر مهاجم مالک دامنه باشد، تغییر رکوردهای آن می‌تواند کاملاً معتبر باشد. DNSSEC بیشتر برای تأیید اصالت و Integrity پاسخ DNS کاربرد دارد و DNS Rebinding کلاسیک را به‌تنهایی متوقف نمی‌کند.

آیا HTTPS در برابر DNS Rebinding مفید است؟

بله. TLS Validation می‌تواند مانع مهمی ایجاد کند، زیرا سرور داخلی معمولاً Certificate معتبر برای hostname دامنه مهاجم ندارد. با این حال HTTPS باید یکی از لایه‌های دفاعی باشد و جای Host Validation، Authentication و Authorization را نمی‌گیرد.

آیا localhost در برابر DNS Rebinding امن است؟

صرف localhost بودن یک سرویس تضمین نمی‌کند که رابط HTTP آن از تمام تهدیدهای Browser-Based مصون باشد. سرویس‌های حساس محلی نیز باید Host Validation، Authentication و حداقل سطح دسترسی مناسب داشته باشند.

آیا CORS از DNS Rebinding جلوگیری می‌کند؟

CORS کنترل مهمی برای دسترسی Cross-Origin است، اما راهکار کامل DNS Rebinding نیست. امنیت سرویس باید بر کنترل‌های مستقل مانند Host Validation، Authentication، Authorization، CSRF Protection و محدودسازی شبکه استوار باشد.

بهترین روش جلوگیری از DNS Rebinding چیست؟

یک راهکار واحد وجود ندارد. استفاده همزمان از Host Allowlist، Authentication، Authorization، HTTPS، CSRF Protection، Origin Validation، DNS Rebind Protection، Network Segmentation و مرورگرهای به‌روز بهترین رویکرد است.

آیا روتر خانگی می‌تواند در معرض DNS Rebinding باشد؟

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

آیا DNS Rebinding فقط کاربران عادی را تهدید می‌کند؟

خیر. توسعه‌دهندگان، سازمان‌ها، شبکه‌های شرکتی، تجهیزات IoT، سرویس‌های Development و نرم‌افزارهای دسکتاپی که HTTP API محلی دارند همگی می‌توانند در Threat Model این حمله قرار بگیرند.

چگونه بفهمیم سرویس ما در برابر DNS Rebinding مقاوم است؟

باید بررسی شود که Hostهای ناشناخته رد می‌شوند، عملیات حساس Authentication و Authorization دارند، سرویس فقط به شبکه موردنیاز دسترسی دارد، HTTPS در صورت امکان استفاده شده و کنترل‌های DNS و مرورگر نیز به‌عنوان لایه‌های مکمل فعال هستند. ارزیابی باید در یک محیط مجاز و کنترل‌شده انجام شود.

جمع‌بندی

DNS Rebinding نمونه خوبی از حملاتی است که نشان می‌دهد مرز میان «اینترنت» و «شبکه داخلی» به اندازه گذشته قابل اعتماد نیست.

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

اشتباه اصلی در بسیاری از سیستم‌های آسیب‌پذیر، اعتماد بیش از حد به محل شبکه است.

یک API نباید صرفاً چون روی 127.0.0.1 اجرا می‌شود بدون Authentication باشد.

یک پنل مدیریت نباید صرفاً چون روی 192.168.x.x قرار دارد هر Host Header را قبول کند.

یک دستگاه IoT نباید صرفاً به دلیل قرار گرفتن پشت NAT تمام درخواست‌های LAN را معتبر بداند.

و یک برنامه Server-Side نیز نباید فقط براساس نام دامنه تصمیم بگیرد که مقصد یک درخواست خارجی امن است.

مقابله مؤثر با DNS Rebinding بر پایه دفاع چندلایه است: Host Validation، Authentication، Authorization، CSRF Protection، بررسی Origin، HTTPS، Network Segmentation، DNS Rebind Protection، کنترل صحیح مقصد در URL Fetcherها، Logging مناسب و استفاده از قابلیت‌های امنیتی مرورگر.

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

اگر یک سرویس داخلی تنها به این دلیل امن در نظر گرفته می‌شود که «روی اینترنت نیست»، زمان آن رسیده است که مدل تهدید آن دوباره بررسی شود. امنیت واقعی زمانی ایجاد می‌شود که حتی در صورت رسیدن یک درخواست غیرمنتظره به سرویس، Authentication، Authorization و سایر لایه‌های دفاعی اجازه سوءاستفاده از آن را ندهند.