Subdomain Takeover چیست؟ چگونه از تصاحب زیردامنه‌های سایت جلوگیری کنیم؟

Subdomain Takeover یا تصاحب زیردامنه نوعی ضعف امنیتی است که معمولاً زمانی ایجاد می‌شود که یک رکورد DNS متعلق به زیردامنه همچنان فعال است، اما سرویس یا منبعی که آن رکورد به آن اشاره می‌کند حذف شده یا دیگر تحت کنترل مالک سایت نیست. در چنین شرایطی، اگر سرویس مقصد اجازه ثبت دوباره آن منبع را بدهد، ممکن است شخص دیگری بتواند محتوایی را از زیردامنه معتبر سایت ارائه کند. اصلی‌ترین راه پیشگیری، مدیریت صحیح چرخه عمر DNS، حذف رکوردهای بلااستفاده، استفاده از Domain Verification و پایش مداوم زیردامنه‌ها است.

Subdomain Takeover چیست؟

برای درک Subdomain Takeover ابتدا باید تفاوت میان «مالکیت دامنه» و «مقصدی که DNS به آن اشاره می‌کند» را درک کنیم.

فرض کنید دامنه اصلی یک مجموعه به شکل زیر باشد:

example.com

این مجموعه برای وبلاگ خود زیردامنه زیر را ایجاد می‌کند:

blog.example.com

اما محتوای وبلاگ مستقیماً روی سرور اصلی example.com قرار ندارد. مدیر سایت یک رکورد DNS ایجاد کرده و blog.example.com را به یک سرویس ابری، CDN، پلتفرم میزبانی استاتیک یا سرویس SaaS متصل کرده است.

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

مسئله زمانی آغاز می‌شود که تیم فنی سرویس مقصد را حذف می‌کند اما رکورد DNS مربوط به blog.example.com همچنان باقی می‌ماند.

در این وضعیت، DNS همچنان به کاربران اعلام می‌کند که مقصد blog.example.com همان سرویس قدیمی است، در حالی که آن منبع دیگر وجود ندارد. به چنین رکوردی معمولاً Dangling DNS Record یا رکورد DNS آویزان/رهاشده گفته می‌شود.

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

OWASP نیز Subdomain Takeover را عمدتاً در همین چارچوب توضیح می‌دهد: رکورد DNS به یک Cloud Resource یا سرویس شخص ثالثی اشاره می‌کند که Deprovision شده یا دیگر وجود ندارد و در برخی سرویس‌ها امکان Claim شدن مجدد منبع وجود دارد.

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

Subdomain چیست و چرا زیردامنه‌ها می‌توانند به سرویس‌های مختلف متصل شوند؟

Subdomain یا زیردامنه بخشی از ساختار سلسله‌مراتبی DNS است.

برای مثال:

example.com

دامنه اصلی است، اما موارد زیر زیردامنه محسوب می‌شوند:

blog.example.com

shop.example.com

cdn.example.com

support.example.com

api.example.com

staging.example.com

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

مثلاً:

این معماری کاملاً طبیعی است و در سایت‌های مدرن استفاده گسترده‌ای دارد.

مشکل از زمانی آغاز می‌شود که ارتباط میان DNS و چرخه عمر سرویس مقصد مدیریت نشود.

ممکن است یک تیم DevOps سرویس docs.example.com را حذف کند، اما مدیریت DNS در اختیار تیم دیگری باشد. اگر هیچ فرآیند مشخصی برای اطلاع‌رسانی و حذف رکورد وجود نداشته باشد، CNAME مربوط به آن زیردامنه ممکن است ماه‌ها یا حتی سال‌ها باقی بماند.

از دید کاربر، docs.example.com همچنان بخشی از دامنه معتبر سازمان است؛ بنابراین کنترل چنین زیردامنه‌ای می‌تواند از نظر امنیتی بسیار مهم باشد.

Subdomain Takeover چگونه ایجاد می‌شود؟

Subdomain Takeover بیشتر از آنکه نتیجه یک نقص در پروتکل DNS باشد، نتیجه یک مشکل در مدیریت چرخه عمر زیرساخت است.

یک سناریوی ساده را در نظر بگیرید.

در مرحله اول، سازمان یک سرویس ابری ایجاد می‌کند.

سپس یک زیردامنه مانند:

service.example.com

از طریق DNS به آن سرویس متصل می‌شود.

مدتی بعد پروژه متوقف می‌شود. تیم فنی سرویس ابری را حذف می‌کند، اما رکورد DNS فراموش می‌شود.

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

در DNS سازمان: رکورد همچنان وجود دارد.

در سرویس مقصد: منبع قبلی دیگر وجود ندارد.

این اختلاف همان چیزی است که Dangling DNS ایجاد می‌کند.

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

اما اگر سرویس اجازه دهد شناسه، نام پروژه، Endpoint یا Resource حذف‌شده مجدداً ایجاد شود و مالکیت دامنه نیز به شکل کافی بررسی نشود، خطر Subdomain Takeover به وجود می‌آید.

Microsoft در مستندات امنیت Azure دقیقاً بر این مسئله تأکید می‌کند که باقی ماندن DNS Record پس از Deprovision شدن منبع می‌تواند یک Dangling DNS Entry ایجاد کند و در سرویس‌های مستعد، زمینه تصاحب زیردامنه را فراهم کند.

Dangling DNS چیست؟

اصطلاح Dangling DNS یکی از مهم‌ترین مفاهیم در بحث Subdomain Takeover است.

یک رکورد DNS را می‌توان Dangling در نظر گرفت زمانی که همچنان در Zone دامنه وجود دارد، اما مقصد منطقی آن دیگر معتبر یا تحت کنترل مالک دامنه نیست.

برای مثال:

blog.example.com → old-service.provider.example

ممکن است رکورد CNAME هنوز وجود داشته باشد اما old-service.provider.example دیگر به هیچ Resource فعالی تعلق نداشته باشد.

از دید DNS، رکورد وجود دارد.

از دید زیرساخت، سرویس وجود ندارد.

همین فاصله میان «وضعیت DNS» و «وضعیت واقعی Resource» یکی از دلایل اصلی بروز Subdomain Takeover است.

چرا Dangling DNS ایجاد می‌شود؟

در عمل دلایل متعددی وجود دارد:

• حذف یک پروژه آزمایشی بدون پاک‌سازی DNS
• مهاجرت از یک CDN به CDN دیگر
• تغییر سرویس Help Desk یا SaaS
• حذف Storage Bucket قدیمی
• حذف Cloud Application
• پایان همکاری با یک سرویس شخص ثالث
• حذف محیط Staging یا Development
• تغییر زیرساخت پس از ادغام شرکت‌ها
• فراموش شدن زیردامنه‌های قدیمی
• نبود Inventory متمرکز برای DNS
• مدیریت جداگانه DNS و Cloud Infrastructure توسط تیم‌های مختلف

OWASP یکی از عوامل اساسی را همین جدایی میان Provisioning زیرساخت و مدیریت DNS می‌داند. منابع Cloud ممکن است مرتب ساخته و حذف شوند، اما رکوردهای DNS معمولاً تا زمانی که کسی صراحتاً آن‌ها را حذف نکند باقی می‌مانند.

آیا هر رکورد DNS خراب به Subdomain Takeover منجر می‌شود؟

خیر.

این یکی از رایج‌ترین برداشت‌های اشتباه درباره Subdomain Takeover است.

ممکن است یک زیردامنه به Resource حذف‌شده اشاره کند اما هیچ راهی برای تصاحب آن توسط شخص ثالث وجود نداشته باشد.

برای آسیب‌پذیری واقعی معمولاً چند شرط باید هم‌زمان برقرار باشد:

1. یک DNS Record متعلق به سازمان وجود داشته باشد.
2. رکورد به Resource یا سرویس خارجی اشاره کند.
3. Resource اصلی حذف یا آزاد شده باشد.
4. سرویس‌دهنده اجازه تخصیص مجدد Resource یا Hostname را بدهد.
5. کنترل مالکیت دامنه مانع استفاده شخص ثالث نشود.

اگر شرط پنجم وجود داشته باشد، یعنی سرویس‌دهنده قبل از اتصال Custom Domain مالکیت دامنه را به شکل معتبر بررسی کند، صرف باقی ماندن CNAME معمولاً برای تصاحب کافی نیست.

به همین دلیل ارزیابی Subdomain Takeover نباید فقط براساس پاسخ DNS یا مشاهده یک خطای HTTP انجام شود.

یک ارزیابی امنیتی حرفه‌ای باید مشخص کند:

• مقصد DNS چیست؟
• سرویس‌دهنده چه کسی است؟
• Resource هنوز وجود دارد یا خیر؟
• Custom Domain چگونه تأیید می‌شود؟
• آیا سرویس Domain Verification دارد؟
• آیا Resource Name قابل استفاده مجدد است؟
• آیا سرویس‌دهنده Reservation یا Ownership Protection ارائه می‌کند؟

بنابراین تفاوت مهمی میان Dangling DNS و Exploitable Subdomain Takeover وجود دارد.

Dangling DNS یک وضعیت پیکربندی نامناسب است، اما قابلیت تصاحب نیازمند شرایط دیگری نیز هست.

چه رکوردهای DNS می‌توانند در معرض خطر باشند؟

وقتی صحبت از Subdomain Takeover می‌شود، بیشتر تمرکز روی رکورد CNAME است؛ زیرا بسیاری از سرویس‌های Cloud، CDN و SaaS از CNAME برای اتصال Custom Domain استفاده می‌کنند.

اما مسئله فقط به CNAME محدود نیست.

CNAME Record

CNAME یکی از رایج‌ترین رکوردهای مرتبط با Subdomain Takeover است.

برای مثال:

docs.example.com → project.hosting-provider.example

اگر Resource مربوط به project حذف شود ولی CNAME باقی بماند، باید بررسی شود آیا سرویس مقصد امکان استفاده مجدد از آن Resource را می‌دهد یا خیر.

Microsoft نیز اشاره می‌کند که CNAMEها در سناریوهای Dangling DNS اهمیت ویژه‌ای دارند.

NS Record

نوع دیگری از خطر به Dangling NS Delegation مربوط می‌شود.

یک سازمان ممکن است مدیریت DNS یک زیردامنه را به مجموعه‌ای از Name Serverها واگذار کرده باشد.

برای مثال، دامنه اصلی تحت کنترل یک DNS Provider است اما:

dev.example.com

به Hosted Zone دیگری Delegate شده است.

اگر Hosted Zone مقصد حذف شود اما NS Recordهای Parent Zone باقی بمانند، وضعیت خطرناکی ایجاد می‌شود.

AWS در مستندات Route 53 به‌طور مشخص درباره Dangling Delegation Records هشدار داده و توصیه می‌کند NSهای Parent همیشه با Delegation Set واقعی Hosted Zone تحت کنترل سازمان تطابق داشته باشند.

این نوع اشتباه می‌تواند از CNAME Takeover نیز مهم‌تر باشد؛ زیرا در Delegation، کنترل بالقوه ممکن است به یک شاخه کامل از Namespace مربوط شود.

A و AAAA Record

رکوردهای A و AAAA یک نام را مستقیماً به IP متصل می‌کنند.

این رکوردها در همه شرایط مشابه CNAME قابل تصاحب نیستند، اما باقی ماندن آن‌ها پس از آزاد شدن IP یا تغییر مالکیت زیرساخت می‌تواند خطر ایجاد کند.

بنابراین IP Address Lifecycle نیز باید بخشی از فرآیند Asset Management باشد.

MX Record

رکورد MX برای مسیریابی ایمیل استفاده می‌شود.

رها شدن سرویس ایمیل یا زیرساخت مرتبط با یک Subdomain می‌تواند تأثیراتی فراتر از نمایش یک صفحه وب داشته باشد.

در محیط‌های سازمانی باید DNS Audit فقط به HTTP و HTTPS محدود نشود و رکوردهای MX، NS، TXT و سایر رکوردهای مرتبط نیز بررسی شوند.

تفاوت Subdomain Takeover با DNS Hijacking چیست؟

Subdomain Takeover و DNS Hijacking دو مفهوم متفاوت هستند.

در DNS Hijacking مهاجم معمولاً به نوعی توانایی تغییر مستقیم DNS یا مسیر پاسخ‌های DNS را به دست می‌آورد. این اتفاق ممکن است به دلیل سرقت حساب Registrar، دسترسی غیرمجاز به DNS Provider، Credential Compromise یا حمله به زیرساخت DNS رخ دهد.

اما در Subdomain Takeover معمولاً مهاجم نیازی به ورود به پنل DNS سازمان ندارد.

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

اشکال اینجاست که مقصد آن رکورد دیگر به Resource تحت کنترل سازمان متصل نیست.

در نتیجه می‌توان گفت:

این تفاوت از نظر Incident Response نیز مهم است. مشاهده محتوای ناشناس روی یک Subdomain لزوماً به معنی هک شدن DNS Provider نیست.

چرا Subdomain Takeover خطرناک است؟

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

اما از دید امنیتی، نام دامنه بخشی از Trust Boundary سازمان محسوب می‌شود.

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

برای مثال:

offers.example.com

از دید کاربر بسیار معتبرتر از یک دامنه ناشناس است.

به همین دلیل تصاحب یک Subdomain می‌تواند چند پیامد مهم داشته باشد.

سوءاستفاده از اعتبار برند و حملات Phishing

یکی از واضح‌ترین خطرها، استفاده از زیردامنه معتبر برای Phishing است.

اگر شخصی بتواند محتوای دلخواه را از:

login.example.com

یا:

support.example.com

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

حتی کاربران فنی نیز معمولاً هنگام ارزیابی یک لینک، Domain Name را یکی از نشانه‌های اعتبار در نظر می‌گیرند.

بنابراین Subdomain Takeover می‌تواند کیفیت و باورپذیری حملات Social Engineering را به شکل قابل توجهی افزایش دهد.

Microsoft نیز Phishing Campaign را یکی از پیامدهای مستقیم تصاحب زیردامنه عنوان می‌کند.

خطر برای Cookieها و Session

یکی از موضوعات حساس در Subdomain Takeover، نحوه تعریف Scope کوکی‌ها است.

اگر یک سایت Cookie را به شکلی تنظیم کند که برای دامنه والد و زیردامنه‌ها معتبر باشد، یک Subdomain ناامن می‌تواند Trust Boundary سایت را گسترده‌تر از حد مورد نیاز کند.

MDN توضیح می‌دهد که تنظیم Domain در Cookie می‌تواند آن Cookie را برای Subdomainهای مرتبط نیز در دسترس قرار دهد و حتی یک برنامه روی Subdomain ممکن است Cookieهایی با Domain والد ایجاد کند؛ به همین دلیل محدود کردن Scope کوکی یک اصل مهم دفاعی است.

البته خطر دقیق به ویژگی‌های Cookie، معماری برنامه، SameSite، HttpOnly، Secure، Scope دامنه و نحوه مدیریت Session بستگی دارد.

در نتیجه نمی‌توان گفت هر Subdomain Takeover الزاماً Session اصلی سایت را افشا می‌کند.

اما وجود Cookieهای گسترده مانند Cookieهایی که برای .example.com تعریف شده‌اند باید هنگام Threat Modeling به‌عنوان یک عامل ریسک بررسی شود.

راهکار دفاعی برای Cookie

تا جای ممکن Cookie حساس را فقط برای Host موردنیاز تعریف کنید.

اگر برنامه نیازی ندارد Session دامنه اصلی در تمام Subdomainها قابل استفاده باشد، Scope را به دامنه والد گسترش ندهید.

همچنین استفاده مناسب از:

Secure

HttpOnly

SameSite

و در شرایط مناسب Cookie Prefixهایی مانند __Host-

می‌تواند بخشی از Defense in Depth باشد.

خطر برای OAuth و SSO

بسیاری از سیستم‌های مدرن از OAuth، OpenID Connect یا Single Sign-On استفاده می‌کنند.

در این سیستم‌ها معمولاً مجموعه‌ای از Redirect URIهای مجاز تعریف می‌شود.

اگر یک Subdomain قدیمی هنوز در تنظیمات Identity Provider به‌عنوان Redirect URI مجاز ثبت شده باشد، تصاحب همان Subdomain می‌تواند ریسک امنیتی را افزایش دهد.

به همین دلیل فرآیند حذف یک سرویس نباید فقط شامل DNS و سرور باشد.

موارد زیر نیز باید بررسی شوند:

• OAuth Redirect URIها
• SAML Endpointها
• Webhookها
• API Callbackها
• CORS Allowlist
• CSP Allowlist
• Allowed Origins
• Third-party Integrations

یک Subdomain ممکن است دیگر روی سایت اصلی لینک نشده باشد، اما همچنان در یکی از تنظیمات قدیمی Identity یا API مورد اعتماد قرار داشته باشد.

خطر برای Content Security Policy و CORS

گاهی توسعه‌دهندگان برای ساده‌تر شدن مدیریت، تمام Subdomainهای سازمان را Trusted در نظر می‌گیرند.

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

هرچه Trust به شکل Wildcard گسترده‌تر تعریف شود، اهمیت امنیت تک‌تک Subdomainها بیشتر می‌شود.

اگر برنامه‌ای به همه زیردامنه‌ها اعتماد کند، یک Subdomain رهاشده می‌تواند در مدل امنیتی سیستم اثر بگذارد.

این موضوع به‌خصوص هنگام بررسی موارد زیر اهمیت دارد:

• CSP
• CORS
• postMessage
• OAuth
• API Allowlist
• iframe Policy
• Trusted JavaScript Sources

اصل کلی این است که به جای اعتماد به *.example.com، در صورت امکان فقط Hostهای مشخص و ضروری Allow شوند.

تأثیر Subdomain Takeover بر SEO و اعتبار سایت

Subdomain Takeover تنها یک موضوع فنی نیست.

اگر روی یک زیردامنه متعلق به برند محتوای Spam، Phishing، Malware یا صفحات نامرتبط منتشر شود، ممکن است اعتبار برند آسیب ببیند.

کاربران ممکن است گزارش‌های امنیتی ثبت کنند.

مرورگرها و سرویس‌های Reputation ممکن است زیردامنه را مشکوک تشخیص دهند.

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

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

بنابراین پاک‌سازی DNS علاوه بر Cybersecurity، بخشی از مدیریت Reputation و Attack Surface نیز محسوب می‌شود.

رایج‌ترین سناریوهای Subdomain Takeover

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

همین موضوع سطح حمله را گسترش داده است.

سرویس‌های Static Hosting

سایت‌های مستندات، Landing Pageها یا وبلاگ‌های کوچک گاهی روی سرویس‌های Static Hosting قرار می‌گیرند.

سازمان یک Custom Domain ایجاد می‌کند و بعداً پروژه را حذف می‌کند.

اگر DNS پاک نشود، باید بررسی شود سرویس Hosting چه مکانیزمی برای Domain Ownership دارد.

Cloud Application Platforms

محیط‌های Cloud App اغلب برای هر Application یک Hostname اختصاصی می‌سازند.

اگر Application حذف شود ولی CNAME باقی بماند، ممکن است Dangling DNS ایجاد شود.

Microsoft برای کاهش این ریسک در Azure App Service استفاده از Domain Verification ID و رکورد TXT مربوط به آن را توصیه می‌کند. بر اساس مستندات رسمی Azure، وجود چنین Verification Recordهایی می‌تواند مانع Validate شدن Custom Domain توسط Subscription دیگری شود.

CDN

زیردامنه‌هایی مانند:

static.example.com

assets.example.com

media.example.com

اغلب به CDN متصل هستند.

هنگام مهاجرت از CDN قدیمی، رکوردهای DNS قبلی باید بخشی از Migration Checklist باشند.

در برخی CDNها برای افزودن Alternate Domain باید مالکیت دامنه یا Certificate معتبر تأیید شود. برای نمونه مستندات فعلی Amazon CloudFront الزام می‌کند Alternate Domain توسط TLS Certificate معتبر پوشش داده شود و همچنین توصیه می‌کند هنگام حذف یک Alternate Domain، DNS نیز به شکل هماهنگ به‌روزرسانی یا حذف شود.

SaaS و Help Desk

بسیاری از سرویس‌های Ticketing، Help Center، Marketing، Documentation و Landing Page اجازه اتصال Custom Domain می‌دهند.

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

به همین دلیل Vendor Offboarding باید DNS Review داشته باشد.

Object Storage

Storageهای ابری نیز ممکن است از Custom Domain استفاده کنند.

در چنین معماری‌هایی باید بررسی شود:

• نام Resource قابل استفاده مجدد است یا خیر؟
• سرویس Ownership Verification دارد یا خیر؟
• Endpoint هنگام حذف Resource چه رفتاری دارد؟
• DNS به Resource مشخص متصل است یا به یک Alias امن؟

نباید صرفاً فرض کرد چون یک Provider مشهور است، Dangling Record هیچ خطری ندارد.

NS Delegation

در سازمان‌هایی که بخش‌های مختلف زیرساخت توسط تیم‌ها یا Providerهای متفاوت مدیریت می‌شوند، ممکن است یک Subdomain به Name Server دیگری Delegate شود.

اگر Hosted Zone مقصد حذف شود و Delegation باقی بماند، نوع متفاوتی از Dangling DNS ایجاد می‌شود.

AWS Route 53 برای برخی سناریوها کنترل‌های محافظتی دارد، اما مستندات AWS صراحتاً اشاره می‌کنند که همه حالات Dangling Delegation به‌صورت خودکار قابل جلوگیری نیستند و Parent NS Recordها باید با Hosted Zone واقعی و تحت کنترل سازمان همگام باشند.

چگونه Subdomain Takeover را به‌صورت دفاعی شناسایی کنیم؟

هدف از بررسی امنیتی نباید تلاش برای تصاحب Resource دیگران باشد.

یک سازمان برای ارزیابی دارایی‌های خودش می‌تواند فرآیندی ایمن و غیرتهاجمی ایجاد کند.

اولین مرحله، Asset Discovery است.

باید بدانید دقیقاً چه Subdomainهایی در اختیار سازمان قرار دارند.

در یک سایت کوچک شاید فقط موارد زیر وجود داشته باشد:

www

mail

shop

blog

اما در یک سازمان بزرگ ممکن است صدها یا هزاران Subdomain وجود داشته باشد.

مرحله اول: ساخت Inventory زیردامنه‌ها

Inventory باید حداقل شامل موارد زیر باشد:

هدف این جدول فقط مستندسازی نیست.

وقتی Resource حذف می‌شود باید بتوان مشخص کرد چه DNS Recordهایی به آن وابسته‌اند.

مرحله دوم: بررسی DNS Resolution

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

اگر CNAME به Hostی اشاره می‌کند که دیگر Resolve نمی‌شود یا پاسخ غیرمنتظره‌ای دارد، باید بررسی انجام شود.

اما صرف NXDOMAIN یا Error به معنی Takeover نیست.

این فقط Signal است.

مرحله سوم: تطبیق DNS با Cloud Inventory

این یکی از مؤثرترین کنترل‌ها است.

فرض کنید ۱۰۰ CNAME به Azure، AWS، CDN و SaaSهای مختلف دارید.

DNS Inventory باید با Resource Inventory مقایسه شود.

اگر:

service.example.com

به Resource X اشاره می‌کند، اما Resource X در هیچ Account سازمانی وجود ندارد، وضعیت باید بررسی شود.

Microsoft نیز توصیه می‌کند رکوردهای DNS با فهرست Resourceهای واقعی مقایسه شوند و مالکیت منابع مقصد تأیید شود.

مرحله چهارم: بررسی پاسخ HTTP و TLS

اگر Subdomain برای وب استفاده می‌شود، تغییرات ناگهانی در HTTP Response می‌تواند نشانه مهمی باشد.

برای مثال:

• صفحه‌ای که قبلاً Application سازمان بود تبدیل به Generic Error شده است.
• Certificate تغییر کرده است.
• Server Header یا CDN Provider تغییر کرده است.
• Status Code غیرمنتظره است.
• محتوای ناشناس نمایش داده می‌شود.

این موارد باید Alert ایجاد کنند، اما هیچ‌کدام به‌تنهایی اثبات Takeover نیستند.

مرحله پنجم: بررسی Certificate Transparency

صدور TLS Certificate جدید برای Subdomainهای سازمان می‌تواند یک Event امنیتی مهم باشد.

Certificate Transparency Logها امکان مشاهده Certificateهای صادرشده برای دامنه‌ها را فراهم می‌کنند.

برای سازمان‌های حساس، مانیتورینگ صدور Certificate جدید می‌تواند به کشف:

• Subdomain ناشناخته
• Certificate غیرمنتظره
• Shadow IT
• تغییر Provider
• Misconfiguration

کمک کند.

این کنترل بهتر است در کنار DNS Monitoring استفاده شود، نه به‌عنوان جایگزین آن.

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

مؤثرترین دفاع این است که اصولاً Dangling DNS ایجاد نشود.

به عبارت دیگر امنیت باید از مرحله Decommissioning آغاز شود، نه زمانی که Scanner یک مشکل را پیدا کرده است.

قبل از حذف سرویس، DNS را مدیریت کنید

یکی از مهم‌ترین قواعد این است:

ابتدا وابستگی DNS را مدیریت کنید، سپس Resource را حذف کنید.

اگر ابتدا Resource ابری حذف شود و CNAME همچنان فعال بماند، یک Window of Exposure ایجاد می‌شود.

OWASP در راهنمای Subdomain Takeover Prevention ترتیب امن Decommissioning را بر مدیریت یا حذف DNS پیش از حذف نهایی Cloud Resource استوار می‌داند.

یک فرآیند منطقی می‌تواند چنین باشد:

1. مشخص کنید چه Domain و Subdomainهایی به Resource متصل هستند.
2. سرویس را از مسیر اصلی کاربران خارج کنید.
3. DNS را به مقصد جدید تحت کنترل منتقل کنید یا رکورد بلااستفاده را حذف کنید.
4. حداقل زمان لازم برای TTL و Propagation در طراحی Migration لحاظ شود.
5. وابستگی‌های OAuth، CORS، CSP، Webhook و API بررسی شوند.
6. پس از اطمینان از قطع وابستگی‌ها، Resource قدیمی Decommission شود.
7. مانیتورینگ پس از تغییر ادامه پیدا کند.

این ترتیب باید جزو SOP یا Standard Operating Procedure تیم DevOps باشد.

از Domain Verification استفاده کنید

یکی از مهم‌ترین تحولاتی که سرویس‌دهندگان ابری برای مقابله با Subdomain Takeover ایجاد کرده‌اند، استفاده از Domain Ownership Verification است.

در این مدل، داشتن یک CNAME به‌تنهایی برای اتصال Custom Domain کافی نیست.

مالک باید از طریق روشی مانند:

• DNS TXT Record
• Verification Token
• TLS Certificate
• حساب سازمانی
• Domain Validation

ثابت کند کنترل دامنه را در اختیار دارد.

نمونه Azure

Azure App Service از Domain Verification ID استفاده می‌کند.

Microsoft توصیه می‌کند هنگام ایجاد Custom Domain رکورد TXT مخصوص Verification نیز ایجاد شود. این رکورد باعث می‌شود Subscription دیگر نتواند بدون اثبات مالکیت، همان Custom Domain را Validate کند.

نمونه GitHub Pages

GitHub نیز برای GitHub Pages امکان Domain Verification دارد.

طبق مستندات رسمی GitHub، Verify کردن Custom Domain کمک می‌کند سایر کاربران نتوانند Domain تأییدشده را برای GitHub Pages خود Claim کنند. GitHub همچنین اعلام می‌کند Verification دامنه می‌تواند Subdomainهای مستقیم آن را نیز تحت پوشش قرار دهد.

این قابلیت‌ها نشان می‌دهند که ارزیابی Subdomain Takeover باید براساس رفتار امروزی هر Provider انجام شود، نه صرفاً لیست‌های قدیمی اینترنتی.

DNS Inventory داشته باشید

هر DNS Record باید Owner داشته باشد.

نباید رکوردی وجود داشته باشد که هیچ‌کس نداند:

• چرا ساخته شده است؟
• متعلق به کدام پروژه است؟
• مقصد آن چیست؟
• چه کسی مجاز به حذف آن است؟
• آیا هنوز مورد استفاده است؟

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

برای سازمان‌های بزرگ‌تر، بهتر است DNS Inventory با CMDB یا سیستم Asset Management یکپارچه شود.

DNS را با Infrastructure as Code مدیریت کنید

استفاده از Infrastructure as Code یا IaC یکی از روش‌های مؤثر کاهش Config Drift است.

ابزارهایی مثل Terraform و سیستم‌های مشابه اجازه می‌دهند DNS و Cloud Resource تا حد امکان در یک Lifecycle مشترک قرار بگیرند.

مزیت اصلی این رویکرد فقط Automation نیست.

مزایای امنیتی آن شامل موارد زیر است:

• تغییرات قابل Review هستند.
• تاریخچه تغییرات وجود دارد.
• حذف Resource می‌تواند همراه با حذف DNS طراحی شود.
• Drift راحت‌تر شناسایی می‌شود.
• مالکیت Infrastructure شفاف‌تر است.
• Rollback امکان‌پذیرتر می‌شود.

مهم‌تر از ابزار، اصل Lifecycle Coupling است: DNS نباید به‌عنوان دارایی جدا از Application مدیریت شود.

از Wildcard DNS با احتیاط استفاده کنید

رکوردهایی مانند:

*.example.com

هر Subdomain تطبیق‌داده‌شده را به یک مقصد مشخص هدایت می‌کنند.

Wildcard DNS در برخی معماری‌ها ضروری است، اما Attack Surface را پیچیده‌تر می‌کند.

اگر واقعاً به Wildcard نیاز دارید:

• محدوده آن را کوچک نگه دارید.
• به جای *.example.com در صورت امکان از *.apps.example.com استفاده کنید.
• Reverse Proxy فقط Hostnameهای مجاز را قبول کند.
• Host Headerهای ناشناخته Reject شوند.
• Application Routing دارای Allowlist باشد.
• Certificate Issuance پایش شود.

Wildcard نباید جایگزین Inventory واقعی Subdomainها شود.

Alias Recordها و وابستگی‌های Lifecycle

برخی Cloud Providerها قابلیت‌هایی ارائه می‌کنند که DNS Record را مستقیماً به یک Resource ID متصل می‌کند.

در این معماری‌ها حذف Resource می‌تواند باعث شود رکورد به شکل امن‌تری بی‌اثر شود و به یک Hostname قابل بازیابی توسط کاربر دیگر اشاره نکند.

Microsoft برای بعضی Resourceهای Azure استفاده از Azure DNS Alias Record را به‌عنوان یکی از کنترل‌های کاهش Dangling Reference معرفی می‌کند. البته این قابلیت برای همه نوع Resource در دسترس نیست و باید براساس مستندات سرویس بررسی شود.

Cookie Scope را محدود کنید

حتی با بهترین سیستم DNS Management، Defense in Depth ضروری است.

یکی از کنترل‌های مهم کاهش Impact این است که Cookieهای حساس فقط در Hostهایی در دسترس باشند که واقعاً به آن‌ها نیاز دارند.

اگر Authentication فقط روی:

www.example.com

انجام می‌شود، لازم نیست Session Cookie بدون دلیل برای تمام:

*.example.com

قابل استفاده باشد.

MDN توصیه می‌کند Domain و سایر Attributeهای Cookie با دقت انتخاب شوند و اشاره می‌کند که Domain Attribute دامنه دسترسی Cookie را به Subdomainها گسترش می‌دهد.

CORS و CSP را براساس Least Privilege تنظیم کنید

همان اصل Least Privilege که برای User Permission استفاده می‌شود باید برای Domain Trust نیز اعمال شود.

به جای اینکه همه زیردامنه‌ها Trusted باشند، فقط Origin یا Hostهایی را Allow کنید که واقعاً مورد نیازند.

برای مثال، اگر فقط:

api.example.com

باید به Frontend دسترسی داشته باشد، اعتماد گسترده به تمام *.example.com ممکن است غیرضروری باشد.

این اصل در تنظیم:

• CORS
• CSP
• OAuth
• Webhook
• SSO
• Trusted Origins

بسیار مهم است.

فرآیند Vendor Offboarding ایجاد کنید

وقتی یک SaaS حذف می‌شود، فقط لغو Subscription کافی نیست.

یک Checklist مناسب باید بپرسد:

آیا Custom Domain وجود داشت؟

آیا CNAME حذف شده است؟

آیا Verification Token حذف یا حفظ آن تصمیم‌گیری شده است؟

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

آیا OAuth Integration وجود دارد؟

آیا API Key باید Revoke شود؟

آیا Certificate مرتبط وجود دارد؟

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

این فرآیند به‌خصوص برای سرویس‌هایی مانند Help Desk، Marketing Platform، Documentation Hosting، CDN و Analytics اهمیت دارد.

Subdomain Takeover در سایت‌های وردپرسی چگونه رخ می‌دهد؟

WordPress به‌تنهایی علت Subdomain Takeover نیست.

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

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

برای مثال:

cdn.example.com

برای CDN،

shop.example.com

برای فروشگاه،

support.example.com

برای Help Desk،

static.example.com

برای Assetهای استاتیک،

staging.example.com

برای نسخه آزمایشی،

و:

blog.example.com

برای نصب جداگانه وردپرس.

بنابراین حتی اگر WordPress Core، افزونه‌ها و قالب کاملاً به‌روز باشند، یک Dangling DNS Record می‌تواند در سطح Domain Attack Surface مشکل ایجاد کند.

تغییر CDN در وردپرس

فرض کنید سایت قبلاً از CDN A استفاده می‌کرده و:

cdn.example.com

به آن متصل بوده است.

بعد از مهاجرت به CDN B ممکن است URLهای وردپرس اصلاح شوند اما CNAME قدیمی همچنان در DNS Zone باقی بماند.

این رکورد باید پاک‌سازی شود.

حذف Staging

محیط‌های آزمایشی یکی از منابع رایج Shadow Infrastructure هستند.

تیم توسعه یک محیط:

staging.example.com

می‌سازد.

بعد از پایان پروژه Server یا Cloud App حذف می‌شود، ولی DNS باقی می‌ماند.

به همین دلیل Staging Environment باید تاریخ انقضا، Owner و Decommission Checklist داشته باشد.

تغییر سرویس پشتیبانی

بسیاری از سایت‌ها:

support.example.com

را به یک SaaS متصل می‌کنند.

اگر سرویس تغییر کند باید CNAME، Verification Recordها، OAuth Integrationها و لینک‌های قدیمی بررسی شوند.

آیا WAF می‌تواند جلوی Subdomain Takeover را بگیرد؟

معمولاً نه، حداقل نه به‌عنوان کنترل اصلی.

WAF یا Web Application Firewall روی Trafficی اثر دارد که از زیرساخت تحت کنترل شما عبور می‌کند.

اگر DNS یک Subdomain مستقیماً به Resource خارجی رهاشده اشاره کند و Traffic دیگر به WAF شما نرسد، WAF لزوماً قادر به جلوگیری از مشکل نیست.

این یکی از دلایلی است که Subdomain Takeover باید در سطح:

• DNS
• Cloud Asset Management
• Domain Verification
• DevOps Process
• Attack Surface Management

کنترل شود.

WAF همچنان برای حفاظت از برنامه‌های فعال مهم است، اما جایگزین DNS Hygiene نیست.

آیا SSL/TLS از Subdomain Takeover جلوگیری می‌کند؟

صرف فعال بودن HTTPS تضمین نمی‌کند Subdomain در برابر Takeover امن است.

نکته تعیین‌کننده این است که سرویس مقصد برای افزودن Custom Domain چه نوع Ownership Verification انجام می‌دهد.

برخی سرویس‌ها از TLS Certificate به‌عنوان بخشی از اثبات مالکیت استفاده می‌کنند.

برای نمونه CloudFront برای افزودن Alternate Domain Name الزام می‌کند نام دامنه توسط Certificate معتبر پوشش داده شود.

در چنین معماری‌هایی TLS بخشی از کنترل مالکیت است.

اما مشاهده آیکون قفل در مرورگر به‌تنهایی نباید به‌عنوان اثبات سالم بودن کل زنجیره Infrastructure در نظر گرفته شود.

چرا لیست‌های قدیمی سرویس‌های آسیب‌پذیر قابل اعتماد نیستند؟

در اینترنت فهرست‌های زیادی وجود دارد که سرویس‌های مختلف را به‌عنوان «آسیب‌پذیر در برابر Subdomain Takeover» معرفی می‌کنند.

مشکل این است که رفتار Cloud Providerها دائماً تغییر می‌کند.

یک سرویس ممکن است چند سال پیش Custom Domain را بدون Verification مناسب Accept کرده باشد اما اکنون:

• TXT Verification اضافه کرده باشد.
• Resource Name Reservation داشته باشد.
• TLS Ownership Validation انجام دهد.
• Hostname را برای Tenant قبلی رزرو کند.
• Secure Unique Hostname ایجاد کند.

برای مثال Azure در نسخه‌های جدید App Service کنترل‌هایی مانند Domain Verification و Secure Unique Default Hostname ارائه می‌دهد.

GitHub نیز Domain Verification را برای کاهش خطر Takeover در GitHub Pages مستند کرده است.

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

یک Fingerprint قدیمی یا خطای HTTP تاریخی نمی‌تواند به‌تنهایی اثبات آسیب‌پذیری باشد.

چگونه DNS Audit دوره‌ای انجام دهیم؟

DNS Audit بهتر است بخشی از برنامه منظم Security Review باشد.

در سایت‌های کوچک می‌توان این بررسی را هنگام هر تغییر زیرساخت انجام داد.

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

یک DNS Audit دفاعی می‌تواند شامل مراحل زیر باشد:

بررسی تمام Zoneها

همه Public DNS Zoneهای سازمان باید Inventory شوند.

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

دامنه‌های:

• قدیمی
• برندهای فرعی
• پروژه‌ها
• دامنه‌های بین‌المللی
• دامنه‌های خریداری‌شده
• دامنه‌های Redirect

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

بررسی تمام CNAMEها

CNAMEهای متصل به سرویس‌های شخص ثالث معمولاً اولویت بالاتری برای Review دارند.

برای هر رکورد باید مشخص باشد:

• Provider چیست؟
• Resource وجود دارد؟
• Account مالک Resource چیست؟
• Domain Verification فعال است؟
• Business Owner کیست؟

بررسی NS Delegation

هر Delegation باید با Hosted Zone واقعی مطابقت داشته باشد.

اگر:

dev.example.com

به مجموعه Name Server جداگانه‌ای Delegate شده است، باید تأیید شود آن Zone واقعاً وجود دارد و تحت کنترل سازمان است.

بررسی رکوردهای قدیمی

رکوردهایی که مدت طولانی تغییر نکرده‌اند لزوماً ناامن نیستند، اما ارزش بازبینی دارند.

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

old

test

dev

staging

beta

demo

temp

legacy

campaign

ممکن است به پروژه‌های موقت گذشته مرتبط باشند.

تعیین Owner

هر Record حساس باید Owner داشته باشد.

رکورد بدون Owner یک بدهی امنیتی است.

Monitoring مداوم بهتر از اسکن مقطعی است

Subdomain Takeover معمولاً در لحظه ایجاد DNS Record رخ نمی‌دهد.

ممکن است Resource برای دو سال کاملاً سالم باشد و در یک Deployment ساده حذف شود.

بنابراین اسکن سالانه کافی نیست.

بهتر است Monitoring Event-driven باشد.

برای مثال:

وقتی یک Cloud Resource حذف می‌شود، Pipeline بررسی کند آیا Custom Domain به آن متصل است.

وقتی DNS Record تغییر می‌کند، Change Log ثبت شود.

وقتی Certificate جدید صادر می‌شود، Alert ایجاد شود.

وقتی یک Endpoint مهم پاسخ غیرمنتظره می‌دهد، تیم امنیت مطلع شود.

این رویکرد نسبت به جستجوی دوره‌ای آسیب‌پذیری بسیار مؤثرتر است.

نقش CI/CD در جلوگیری از Subdomain Takeover

CI/CD می‌تواند DNS Hygiene را به بخشی از Deployment تبدیل کند.

برای مثال هنگام ایجاد سرویس:

• DNS Record به شکل IaC ساخته شود.
• Owner به Metadata اضافه شود.
• Verification Record ثبت شود.
• Expiration برای محیط موقت تعیین شود.

هنگام حذف سرویس:

• Pipeline وابستگی DNS را بررسی کند.
• حذف Resource تا تعیین تکلیف DNS Block شود.
• Custom Domain ابتدا Detach شود.
• DNS به مقصد امن منتقل یا حذف شود.
• سپس Resource Decommission شود.

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

چگونه محیط‌های موقت را مدیریت کنیم؟

محیط‌های Preview، QA، Development و Staging یکی از چالش‌های اصلی هستند.

این محیط‌ها زیاد ساخته و حذف می‌شوند.

بهتر است برای آن‌ها Namespace مشخصی در نظر گرفته شود.

برای مثال:

*.staging.example.com

و یک Policy مشخص برای Lifecycle وجود داشته باشد.

هر محیط موقت باید:

• Owner داشته باشد.
• تاریخ ایجاد داشته باشد.
• Expiration Date داشته باشد.
• خودکار حذف شود.
• DNS آن نیز همراه Resource مدیریت شود.

به این ترتیب صدها Subdomain آزمایشی بدون مالک در DNS باقی نمی‌مانند.

اگر احتمال می‌دهیم Subdomain تصاحب شده است چه کار کنیم؟

اگر محتوای ناشناس روی یک زیردامنه مشاهده شد، موضوع باید مانند یک Incident امنیتی بررسی شود.

اولویت اصلی قطع ارتباط DNS با Resource مشکوک است.

۱. DNS را کنترل کنید

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

اگر مقصد دیگر تحت کنترل سازمان نیست، Record باید طبق فرآیند Incident Response حذف یا به Infrastructure امن منتقل شود.

۲. DNS Zone را تغییر غیرمجاز فرض نکنید

مشخص کنید آیا DNS Record اخیراً تغییر کرده یا همان رکورد قدیمی است.

اگر رکورد تغییر نکرده باشد اما مقصد عوض شده باشد، احتمال Dangling Resource مطرح می‌شود.

اگر خود DNS تغییر کرده باشد، باید Credential Compromise یا DNS Account Takeover نیز بررسی شود.

۳. Cloud Accountها را بررسی کنید

مشخص کنید Resource اصلی:

• چه زمانی ساخته شده،
• چه زمانی حذف شده،
• توسط چه حسابی حذف شده،
• آیا Change Log وجود دارد،
• و آیا Decommissioning طبق Policy انجام شده است.

۴. OAuth و Integrationها را بررسی کنید

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

از جمله:

OAuth Redirect URI

SAML

CORS

CSP

Webhook

API Callback

Third-party Allowlist

۵. Sessionها و Cookieها را بررسی کنید

اگر Cookieهای حساس برای Parent Domain تعریف شده‌اند، باید Scope و احتمال تأثیر بر Session ارزیابی شود.

در شرایط لازم ممکن است Revoke کردن Sessionهای فعال یا Rotate کردن Tokenها بخشی از Incident Response باشد.

۶. Certificateها را بررسی کنید

Certificate Transparency و Certificateهای فعال Subdomain را بررسی کنید.

صدور Certificate غیرمنتظره می‌تواند به تعیین Timeline کمک کند.

۷. Logها را حفظ کنید

لاگ‌های DNS Provider، Cloud Provider، CDN، WAF، Application، Identity Provider و Certificate Management باید برای Investigation نگهداری شوند.

۸. علت ریشه‌ای را برطرف کنید

صرف حذف رکورد کافی نیست.

باید مشخص شود چرا Resource بدون حذف DNS Decommission شده است.

در غیر این صورت همان مشکل در پروژه دیگری تکرار خواهد شد.

Microsoft نیز در راهنمای Incident Remediation خود علاوه بر حذف DNS Record، بررسی احتمال Compromise و اصلاح فرآیند Decommissioning را توصیه می‌کند.

اشتباهات رایج در جلوگیری از Subdomain Takeover

حذف Cloud Resource قبل از DNS

این رایج‌ترین اشتباه است.

منبع حذف می‌شود اما CNAME باقی می‌ماند.

ترتیب باید معکوس باشد: ابتدا ارتباط دامنه را مدیریت کنید و سپس Resource را حذف کنید.

تصور اینکه NXDOMAIN یعنی امن بودن

Resolve نشدن مقصد یک علامت است، نه نتیجه نهایی.

باید Provider و قابلیت Reclaim بررسی شود.

اتکا به WAF

WAF نمی‌تواند Resource خارجی را که DNS مستقیماً به آن اشاره می‌کند کنترل کند.

اعتماد به HTTPS

وجود Certificate لزوماً نشان نمی‌دهد Subdomain در اختیار مالک اصلی است.

اعتماد به یک Scanner

Scannerها می‌توانند False Positive داشته باشند.

تأیید نهایی باید با Asset Inventory و مستندات Provider انجام شود.

نادیده گرفتن NS Recordها

تمرکز فقط روی CNAME باعث می‌شود Dangling Delegation دیده نشود.

نگهداری Wildcardهای گسترده

Wildcard DNS و Wildcard Trust در CSP/CORS می‌تواند Impact یک Subdomain ناامن را افزایش دهد.

نداشتن Owner برای DNS

اگر هیچ شخص یا تیمی مسئول یک Record نباشد، احتمال فراموش شدن آن زیاد است.

نادیده گرفتن سرویس‌های قدیمی

بسیاری از مشکلات از پروژه‌هایی ایجاد می‌شوند که سال‌ها پیش متوقف شده‌اند.

چک‌لیست جلوگیری از Subdomain Takeover

برای کاهش ریسک تصاحب زیردامنه، مدیر سایت یا تیم DevOps می‌تواند این چک‌لیست را به‌صورت دوره‌ای اجرا کند:

مدیریت DNS

• همه DNS Zoneها Inventory شده‌اند.
• هر Subdomain دارای Owner مشخص است.
• CNAMEهای متصل به سرویس خارجی ثبت شده‌اند.
• NS Delegationها بررسی می‌شوند.
• DNS Recordهای قدیمی Audit می‌شوند.
• Wildcard Recordها فقط در صورت نیاز استفاده می‌شوند.

مدیریت Cloud Resource

• هر Custom Domain به Resource مشخص متصل است.
• Resourceهای حذف‌شده از Inventory خارج و DNS آن‌ها بررسی می‌شود.
• Decommission Checklist وجود دارد.
• Cloud Asset Inventory با DNS مقایسه می‌شود.
• محیط‌های Staging و Temporary تاریخ انقضا دارند.

Domain Verification

• در سرویس‌های پشتیبانی‌شده TXT Verification فعال است.
• مالکیت Custom Domain مستند است.
• Verification Tokenها بدون دلیل حذف نمی‌شوند.
• قابلیت‌های امنیتی Provider براساس مستندات فعلی بررسی می‌شوند.

امنیت Application

• Cookieهای حساس Domain Scope غیرضروری ندارند.
• CORS روی Originهای مشخص محدود شده است.
• CSP بیش از حد به Wildcard Subdomainها اعتماد ندارد.
• OAuth Redirect URIهای قدیمی حذف شده‌اند.
• Webhookهای قدیمی غیرفعال شده‌اند.
• API Allowlistها Audit می‌شوند.

Monitoring

• تغییرات DNS Log می‌شوند.
• Certificateهای جدید پایش می‌شوند.
• Endpointهای مهم Availability Monitoring دارند.
• پاسخ‌های غیرمنتظره Subdomainها Alert ایجاد می‌کنند.
• Incident Response برای Dangling DNS تعریف شده است.

Subdomain Takeover در تست امنیت سایت چگونه گزارش شود؟

در یک گزارش حرفه‌ای، صرف مشاهده یک DNS Record رهاشده نباید بدون بررسی کافی به‌عنوان «تصاحب قطعی زیردامنه» گزارش شود.

بهتر است Finding با جزئیات زیر ثبت شود:

عنوان: Potential Subdomain Takeover / Dangling DNS

دارایی: Subdomain مورد بررسی

DNS Record: نوع Record و مقصد

Provider: سرویس مقصد

وضعیت Resource: فعال، غیرفعال یا نامشخص

Domain Verification: وجود یا عدم وجود مکانیزم تأیید مالکیت

Impact: تأثیر احتمالی

Confidence: میزان اطمینان

Recommendation: حذف رکورد، اتصال به Resource تحت کنترل یا فعال کردن Verification

این شیوه گزارش‌دهی باعث کاهش False Positive می‌شود و برای تیم فنی قابل اقدام‌تر است.

اولویت‌بندی ریسک Subdomainها

همه Subdomainها اهمیت یکسانی ندارند.

برای مثال تصاحب احتمالی:

old-demo.example.com

ممکن است با:

login.example.com

از نظر Business Impact متفاوت باشد.

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

• آیا Subdomain در سایت اصلی لینک شده است؟
• آیا توسط موتورهای جستجو Index شده است؟
• آیا کاربران آن را می‌شناسند؟
• نام آن حس اعتماد ایجاد می‌کند؟
• Cookieهای Parent Domain چه Scopeی دارند؟
• در OAuth یا SSO Trusted است؟
• در CSP یا CORS Allow شده است؟
• برای Email استفاده می‌شود؟
• حجم Traffic چقدر است؟
• آیا اطلاعات حساس از طریق آن عبور می‌کرده است؟

ترکیب احتمال Exploitability و Business Impact باید شدت Finding را تعیین کند.

Subdomain Takeover و اصل Zero Trust

یکی از درس‌های معماری Subdomain Takeover این است که نباید صرفاً به دلیل قرار داشتن یک Host زیر دامنه سازمان، آن را Trusted دانست.

در گذشته بسیاری از معماری‌ها تمام:

*.example.com

را یک Trust Zone واحد فرض می‌کردند.

اما در معماری Cloud امروزی ممکن است ده‌ها Provider مختلف پشت Subdomainهای یک سازمان قرار داشته باشند.

یکی روی AWS،

یکی روی Azure،

یکی روی SaaS،

یکی روی CDN،

و دیگری روی سرور داخلی.

بنابراین Trust باید به شکل Explicit تعریف شود.

این موضوع با اصول Zero Trust هم‌راستا است: اعتماد باید براساس Identity و Context مشخص ایجاد شود، نه صرفاً شباهت در Namespace.

چه تیم‌هایی باید مسئول جلوگیری از Subdomain Takeover باشند؟

Subdomain Takeover معمولاً یک مشکل بین‌تیمی است.

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

تیم DNS یا Network

مسئول Zone و Recordها است.

تیم DevOps یا Cloud

Resourceهای مقصد را مدیریت می‌کند.

تیم Development

Custom Domain و Integrationها را در برنامه تعریف می‌کند.

تیم Security

Monitoring، Policy، Review و Incident Response را مدیریت می‌کند.

Business Owner

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

اگر این تیم‌ها فرآیند مشترکی نداشته باشند، همان شکافی ایجاد می‌شود که Dangling DNS از آن شکل می‌گیرد.

نقش Asset Management در پیشگیری

یکی از مهم‌ترین درس‌های Subdomain Takeover این است که نمی‌توان چیزی را که نمی‌شناسیم امن نگه داریم.

اگر سازمان نداند چند Subdomain دارد، به چه سرویس‌هایی متصل هستند و چه کسی مسئول آن‌هاست، هیچ Scanner یا WAF نمی‌تواند مسئله را به‌طور کامل حل کند.

Asset Management باید موارد زیر را پوشش دهد:

Domain

Subdomain

IP Address

Cloud Resource

CDN

SaaS

Certificate

DNS Provider

Business Owner

Technical Owner

Lifecycle State

این اطلاعات یک Attack Surface Map ایجاد می‌کند.

منابع معتبر برای بررسی Subdomain Takeover

برای ارزیابی فنی این آسیب‌پذیری بهتر است به منابع اصلی مراجعه شود.

OWASP در Subdomain Takeover Prevention Cheat Sheet ساختار حمله، Dangling DNS، Inventory، Domain Verification، Wildcard DNS، Monitoring و Incident Response را پوشش می‌دهد.

Microsoft در مستندات Azure Security جزئیات Dangling DNS، App Service Domain Verification، Azure DNS Alias و فرآیند Remediation را تشریح کرده است.

GitHub در مستندات GitHub Pages روش Domain Verification و نقش آن در جلوگیری از استفاده کاربران دیگر از Custom Domain را توضیح می‌دهد.

AWS نیز در مستندات Route 53 درباره Dangling Delegation و در مستندات CloudFront درباره مدیریت Alternate Domain Name، Certificate Validation و حذف هماهنگ DNS توضیح داده است.

برای Cookie Security نیز مستندات MDN مرجع مناسبی برای Domain Scope، SameSite، Secure، HttpOnly و Cookie Prefixها محسوب می‌شود.

مهم است که رفتار هر Cloud Provider در زمان ارزیابی مستقیماً از مستندات فعلی همان Provider بررسی شود؛ زیرا مکانیزم‌های Domain Verification و Hostname Reservation می‌توانند در طول زمان تغییر کنند.

سؤالات متداول درباره Subdomain Takeover

Subdomain Takeover چیست؟

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

Dangling DNS چیست؟

Dangling DNS به رکوردی گفته می‌شود که در DNS Zone باقی مانده اما Resource یا Endpoint مقصد آن دیگر وجود ندارد یا تحت کنترل مالک دامنه نیست. Dangling DNS یکی از شرایط اصلی بسیاری از سناریوهای Subdomain Takeover است، اما هر Dangling DNS الزاماً قابل تصاحب نیست.

آیا CNAME همیشه در برابر Subdomain Takeover آسیب‌پذیر است؟

خیر. خطر به سرویس مقصد بستگی دارد. اگر Provider برای Custom Domain از Domain Verification، TLS Validation، Resource Reservation یا کنترل مشابه استفاده کند، وجود CNAME رهاشده لزوماً به تصاحب منجر نمی‌شود.

آیا حذف Subdomain از وردپرس برای رفع مشکل کافی است؟

خیر. WordPress و DNS دو لایه متفاوت هستند. حذف لینک، صفحه یا تنظیمات وردپرس، DNS Record را حذف نمی‌کند. باید DNS Zone و Resource مقصد نیز بررسی شوند.

آیا Cloudflare یا WAF جلوی Subdomain Takeover را می‌گیرد؟

نه در همه معماری‌ها. اگر DNS مستقیماً به یک سرویس خارجی اشاره کند، Traffic ممکن است اصلاً از WAF عبور نکند. کنترل اصلی شامل DNS Lifecycle Management، Domain Verification و Asset Monitoring است.

آیا SSL مانع تصاحب زیردامنه می‌شود؟

وجود HTTPS به‌تنهایی کافی نیست. بعضی Providerها Certificate را برای اثبات مالکیت Custom Domain استفاده می‌کنند که می‌تواند کنترل امنیتی مؤثری باشد، اما صرف مشاهده Certificate معتبر نباید جایگزین بررسی مالکیت Resource شود.

چگونه بفهمیم یک Subdomain در خطر است؟

باید DNS Record، مقصد، وضعیت Resource، مالک آن و Domain Verification Provider بررسی شود. Resolve نشدن Host یا نمایش Error Page صرفاً نشانه نیاز به بررسی است و به تنهایی اثبات آسیب‌پذیری نیست.

مهم‌ترین راه جلوگیری از Subdomain Takeover چیست؟

مهم‌ترین راهکار این است که DNS و Resource Lifecycle با یکدیگر مدیریت شوند. هنگام حذف یک سرویس ابتدا Custom Domain و DNS مربوط به آن تعیین تکلیف شود و سپس Resource حذف شود. Inventory، Verification و Monitoring مداوم نیز باید در کنار این فرآیند قرار گیرند.

جمع‌بندی؛ چگونه جلوی تصاحب زیردامنه را بگیریم؟

Subdomain Takeover یکی از نمونه‌های مهم آسیب‌پذیری‌هایی است که الزاماً از یک باگ برنامه‌نویسی پیچیده ایجاد نمی‌شوند. در بسیاری از موارد مشکل از یک CNAME قدیمی، Hosted Zone فراموش‌شده، محیط Staging حذف‌شده یا سرویس SaaS منقضی‌شده آغاز می‌شود.

ریشه اصلی مشکل معمولاً شکاف میان DNS Lifecycle و Resource Lifecycle است.

تیم Cloud یک Resource را حذف می‌کند، تیم DNS از این اتفاق خبر ندارد و Record همچنان باقی می‌ماند.

برای کاهش این خطر باید مدیریت Subdomainها به بخشی از Attack Surface Management سازمان تبدیل شود.

تمام DNS Recordها باید Owner داشته باشند. Custom Domainها باید Inventory شوند. هنگام Decommission کردن سرویس، DNS پیش از حذف نهایی Resource تعیین تکلیف شود. Domain Verification سرویس‌دهنده‌ها باید فعال باشد و CNAME، NS Delegation، Cloud Endpoint و Certificateها به شکل دوره‌ای پایش شوند.

همچنین باید فرض شود که کنترل یک Subdomain می‌تواند فراتر از نمایش یک صفحه ساده اثر داشته باشد. Cookie Scope، OAuth، SSO، CSP، CORS، Webhookها و اعتبار برند ممکن است به Subdomain اعتماد کرده باشند.

در نهایت، بهترین دفاع در برابر تصاحب زیردامنه این نیست که منتظر بمانیم Scanner یک Dangling DNS پیدا کند؛ بلکه باید فرآیندی ایجاد کنیم که Dangling DNS اساساً ایجاد نشود.

مدیریت هماهنگ DNS و Cloud، استفاده از Domain Verification، محدود کردن Trust میان Subdomainها، پایش دارایی‌ها و داشتن Decommission Checklist می‌تواند احتمال Subdomain Takeover را به میزان قابل توجهی کاهش دهد و یکی از بخش‌های پنهان Attack Surface سایت را تحت کنترل نگه دارد.