Kiểm tra subdomain security là quá trình xác minh mỗi subdomain đang tồn tại có owner rõ ràng, DNS dependency hợp lệ, service đích còn được kiểm soát và không tạo trust relationship vượt quá mức cần thiết. Subdomain thường được tạo nhanh cho staging, marketing, SaaS, CDN, API hoặc chiến dịch ngắn hạn nhưng lại ít được decommission đúng quy trình.
Một subdomain không an toàn chưa chắc bị compromise. Audit cần tách rõ misconfiguration, dangling dependency, excessive trust và takeover đã được xác minh. Bài này cung cấp workflow kiểm tra theo evidence, không dựa vào fingerprint đơn lẻ.
Subdomain security cần kiểm tra những lớp nào?
- Ownership và business purpose.
- DNS record, delegation và dependency.
- Service/resource đứng sau hostname.
- TLS certificate và certificate lifecycle.
- Cookie, CORS, OAuth và web trust boundary.
- Dangling DNS và khả năng subdomain takeover.
- Logging, monitoring và decommission process.
Quy trình kiểm tra Subdomain Security
Bước 1: Inventory toàn bộ subdomain
Inventory nên kết hợp DNS zone, certificate inventory, application/cloud asset và service catalog. Public discovery chỉ cho thấy một phần namespace; nguồn authoritative của tổ chức vẫn quan trọng hơn. Nếu hostname tồn tại nhưng không nằm trong inventory hoặc chưa có owner rõ ràng, xem thêm Shadow Subdomain Risk.
Gắn owner cho từng hostname
Mỗi subdomain quan trọng cần có technical owner, business purpose và dependency. Hostname không có owner chưa chắc phải xóa nhưng là finding cần điều tra.
Bước 2: Phân loại DNS dependency
Với mỗi hostname, ghi record type và target: A/AAAA, CNAME, delegated NS hoặc provider-managed alias. External CNAME/NS cần ưu tiên vì lifecycle phụ thuộc third party.
Nếu target resource đã bị xóa hoặc không còn thuộc owner, đó có thể là dangling DNS. Chỉ nâng thành takeover risk khi có evidence provider cho phép actor khác claim dependency.
Bước 3: Xác minh service đích
DNS resolve đúng chưa đủ. Cần xác minh origin/service thực tế có thuộc subscription/account intended, có còn active và có được team chịu trách nhiệm xác nhận hay không.
Không dựa vào error page duy nhất
Provider-specific error có thể là signal cho resource missing, nhưng behavior thay đổi theo thời gian. Microsoft lưu ý dangling DNS có thể dẫn tới takeover trên các dịch vụ có khả năng claim lại resource, vì vậy cần đối chiếu provider hiện hành và ownership state.
Bước 4: Kiểm tra TLS certificate
Kiểm tra certificate có khớp hostname, còn hiệu lực và được quản lý bởi pipeline intended. Một certificate hợp lệ không chứng minh service đích thuộc đúng owner; attacker kiểm soát hostname trong một số takeover scenario cũng có thể xin certificate hợp lệ.
Bước 5: Review cookie scope
Cookie đặt với Domain=.example.com có thể được gửi tới nhiều subdomain hơn cookie host-only. Nếu một subdomain ít tin cậy hoặc bị takeover, cookie scope rộng có thể tăng impact. Audit nên ghi Domain, Secure, HttpOnly và SameSite cho cookie quan trọng.
Bước 6: Review CORS và browser trust
Không dùng wildcard hoặc regex quá rộng chỉ vì mọi subdomain đều “thuộc công ty”. Một abandoned subdomain vẫn nằm trong namespace nhưng có thể không còn trustworthy. CORS allowlist nên dựa trên application need và owner hiện tại.
Bước 7: Review OAuth/OIDC redirect URI
Subdomain cũ có thể còn nằm trong redirect allowlist của identity provider. Nếu hostname bị takeover, trust relationship này có thể làm impact tăng đáng kể. Review redirect URI, logout URI và callback endpoint khi decommission subdomain.
Bước 8: Kiểm tra dangling DNS và takeover
Workflow an toàn gồm: resolve DNS → xác định provider → đối chiếu resource inventory → xác minh claimability → đánh giá impact. Không tự ý claim production resource nếu chưa có authorization.
Xem chi tiết tại Subdomain Takeover là gì?.
Bước 9: Review delegated subdomain
Subdomain có NS delegation riêng cần biết authoritative provider và team owner. Delegation cũ tới nameserver không còn quản trị có thể gây outage hoặc security risk tùy khả năng kiểm soát infrastructure đích.
Bước 10: Kiểm tra monitoring
Subdomain critical nên có baseline DNS và alert phù hợp cho CNAME/NS/A/AAAA hoặc service state. Khi resource bị deprovision, workflow nên bắt buộc review DNS để tránh dangling dependency.
Xem DNS Change Monitoring để thiết kế baseline và alert.
Đánh giá finding và mức độ ưu tiên
Cách phân loại finding khi audit subdomain
| Finding | Evidence | Ví dụ xử lý |
|---|---|---|
| Unknown owner | Không có team/service nhận trách nhiệm | Điều tra trước khi thay đổi |
| Stale service | Hostname còn nhưng app không còn intended | Decommission có snapshot |
| Dangling DNS | Record còn, dependency mất | Delete/repoint sau xác minh |
| Takeover risk | Dependency claimable | Remediate ưu tiên theo impact |
| Excessive trust | Cookie/CORS/OAuth tin hostname không cần thiết | Thu hẹp trust boundary |
Severity phụ thuộc vào điều gì?
Không nên chấm tất cả abandoned subdomain là High. Hãy xem traffic, authentication flow, cookie scope, CORS/OAuth trust, brand exposure, claimability và mức kiểm soát attacker có thể đạt được.
Checklist kiểm tra Subdomain Security
- Inventory hostname.
- Gắn owner và purpose.
- Ghi DNS type/target.
- Kiểm tra resource ownership.
- Review external CNAME/NS.
- Kiểm tra dangling state.
- Xác minh claimability khi cần.
- Review TLS certificate.
- Review cookie Domain/Secure/HttpOnly/SameSite.
- Review CORS allowlist.
- Review OAuth/OIDC redirect URI.
- Review monitoring.
- Review decommission process.
- Snapshot trước remediation.
- Read-back DNS/service sau change.
Để rà soát toàn bộ registrar, DNS, subdomain và TLS certificate lifecycle theo một checklist thống nhất, xem Domain & DNS Security Checklist.
Audit subdomain nên thu thập evidence gì?
- Hostname, record, target và timestamp.
- Authoritative/public DNS result.
- Cloud/SaaS resource owner.
- HTTP/TLS response.
- Cookie/CORS/OAuth relationship nếu relevant.
- Traffic hoặc business criticality.
- Claimability evidence nếu có.
- Change/rollback plan.
Liên kết với DNS audit
Audit DNS Record kiểm tra zone ở mức record. Subdomain security mở rộng sang application trust và lifecycle của resource đứng sau hostname. Hai workflow nên chia sẻ cùng inventory thay vì tạo hai danh sách độc lập.
Subdomain inventory sheet + ownership/status matrix
Artifact dưới đây là mẫu inventory để copy sang Sheet/CSV, không phải danh sách subdomain thực tế của SecureWebOps.
hostname,dns_type,dns_target,provider,business_purpose,business_owner,technical_owner,resource_account,service_state,tls_state,traffic_state,cookie_scope,cors_trust,oauth_redirect,claimability,monitoring,decommission_state,final_status,next_action,last_verified| Nhóm field | Cách dùng |
|---|---|
| Hostname/DNS | Ghi hostname, record type, target và provider |
| Ownership | Business purpose, business owner, technical owner, resource account |
| Service state | ACTIVE / STALE / UNKNOWN và evidence tương ứng |
| TLS | Expected certificate/pipeline và trạng thái observed |
| Trust | Cookie scope, CORS allowlist, OAuth/OIDC redirect dependency |
| Claimability | NOT_TESTED / NOT_CONFIRMED / CONFIRMED theo evidence và authorization |
| Monitoring | DNS/service alert và owner nhận alert |
| Decommission | KEEP / MIGRATE / DECOMMISSION / INVESTIGATE |
| Final status | PASS / FAIL / NEEDS_INVESTIGATION |
| last_verified | Timestamp + timezone của evidence gần nhất |
Ownership/status decision matrix
| Owner | Service state | Dependency | Trust | Action |
|---|---|---|---|---|
| Known | Active | Valid | Expected | KEEP + monitor |
| Known | Retired | Still present | None/low | Plan DECOMMISSION có snapshot/read-back |
| Unknown | Unknown | External | Any | NEEDS_INVESTIGATION; không tự xóa |
| Known/Unknown | Resource missing | Dangling | Any | Chuyển sang dangling/takeover workflow |
| Known | Active/Retired | Valid | Excessive cookie/CORS/OAuth | Thu hẹp trust theo app need |
Không điền owner, claimability hoặc final status theo suy đoán. Khi evidence chưa đủ, trạng thái đúng là NEEDS_INVESTIGATION.
Nguồn kỹ thuật tham khảo
- Microsoft Learn — Prevent dangling DNS entries and avoid subdomain takeover
- NIST SP 800-81 Rev. 3 — Secure DNS Deployment Guide
Kết luận
Kiểm tra subdomain security không nên dừng ở việc hostname có trả HTTP 200 hay không. Cần xác minh owner, DNS dependency, service ownership và các trust relationship như cookie, CORS và OAuth.
Điểm quan trọng nhất là lifecycle. Khi subdomain được tạo, dependency và owner phải được ghi nhận; khi resource bị xóa, DNS và trust relationship liên quan cũng phải được đóng cùng lúc.