DNS Rebinding Mempertahankan Web Origin Saat Tujuan Jaringan Berubah

Browser dapat menganggap dua request sebagai same-origin meski koneksi TCP di balik keduanya berakhir pada alamat IP yang berbeda. Model origin dibentuk dari scheme, host, dan port pada URL. Resolusi DNS merupakan operasi jaringan di bawah identitas tersebut. Jika sebuah hostname mula-mula mengarah ke satu alamat lalu kemudian ke alamat lain, origin yang terlihat oleh browser dapat tetap sama.

DNS rebinding memanfaatkan pemisahan itu. Hostname yang dikendalikan penyerang dapat mula-mula mengarah ke server milik penyerang yang mengirimkan script, lalu kemudian mengarah ke alamat yang dapat dijangkau dari jaringan korban. Bergantung pada perilaku browser, resolver, transport, dan service tujuan, request berikutnya untuk hostname yang sama dapat melewati batas jaringan tanpa berubah menjadi cross-origin dalam model origin browser.

Teknik ini bukan bypass umum untuk setiap kontrol browser. Dampaknya bergantung pada beberapa pemeriksaan yang berdiri sendiri, dan client modern dapat menambahkan proteksi di luar model same-origin tradisional. Properti keamanan intinya lebih sempit: resolusi DNS tidak menjadikan alamat IP sebagai bagian dari web origin.

Identitas origin tidak mengunci hostname ke satu alamat

Untuk keamanan browser yang berhadapan dengan HTTP, origin diidentifikasi oleh tuple yang berisi scheme, host, dan port. URL seperti http://node.example:8080 karena itu mempertahankan tuple origin yang sama selama node.example tetap menjadi host, terlepas dari alamat yang dikembalikan resolver pada saat tertentu.

DNS, di sisi lain, mengizinkan record berubah. TTL memengaruhi caching, tetapi bukan primitive keamanan origin. Resolusi juga dapat melewati cache browser, cache sistem operasi, recursive resolver, dan komponen lain dengan perilaku refresh yang berbeda.

Kondisi ini menghasilkan beberapa identitas yang berbeda:

Desain keamanan yang menganggap identitas tersebut setara dapat menempatkan service jaringan di belakang batas yang lebih lemah dari yang diperkirakan.

Tujuan dapat berpindah tanpa transisi cross-origin

Urutan rebinding sederhana dimulai dengan hostname yang dikendalikan penyerang. Respons DNS pertama menunjuk ke server yang dapat diakses dari Internet. Browser memuat dokumen dan script dari host tersebut, sehingga membentuk origin seperti:

http://relay.example:8080

Setelah state DNS yang relevan berubah atau kedaluwarsa, lookup berikutnya untuk relay.example dapat mengembalikan alamat berbeda, termasuk alamat loopback, private, atau alamat lain yang dapat dijangkau secara lokal. Koneksi baru kemudian dapat menuju alamat tersebut sementara script tetap mengirim request ke origin URL yang sama.

Perbandingan same-origin di browser tidak memperoleh field alamat IP. Berdasarkan perbandingan itu saja, script masih berkomunikasi dengan http://relay.example:8080.

Perbedaan ini relevan bagi service yang terutama mengandalkan penempatan jaringan. Endpoint administrasi mungkin tidak pernah dirancang untuk menerima request yang dipicu konten web arbitrer karena operator mengasumsikan alamat internal tidak dapat dicapai dari origin Internet. Rebinding menyerang asumsi tersebut pada batas pemetaan nama ke alamat.

HTTP authority tetap menjadi gerbang terpisah

Perubahan alamat hasil resolusi biasanya tidak menulis ulang hostname yang dibawa pada layer HTTP. Untuk HTTP/1.1, request ke hostname yang mengalami rebinding biasanya membawa nilai Host untuk hostname tersebut. HTTP/2 dan HTTP/3 memakai pseudo-header :authority untuk informasi authority yang setara.

Perilaku ini dapat menghentikan serangan jika service tujuan memvalidasi authority yang diharapkan. Service yang dikonfigurasi hanya untuk admin.internal tidak perlu menerima request dengan authority relay.example.

Sebaliknya, service yang menerima nilai host arbitrer, memakai default virtual host, atau mengabaikan authority untuk operasi sensitif dapat menghilangkan gerbang ini. Binding hanya ke interface private tidak memberikan validasi application-layer yang setara.

Validasi host karena itu berguna untuk service yang terekspos melalui HTTP stack yang dapat dijangkau browser, tetapi penerapannya harus sesuai model deployment. Reverse proxy dan service mesh dapat secara sah mengubah metadata routing, sehingga komponen yang menegakkan pemeriksaan harus memakai nilai authority yang mewakili keputusan trust yang dimaksud, bukan forwarded field yang tidak tepercaya.

HTTPS menambahkan identitas sertifikat ke jalur koneksi

TLS mengubah kelayakan koneksi hasil rebinding. Jika script dimuat dari origin HTTPS, koneksi berikutnya ke origin yang sama tetap memerlukan sesi TLS yang dapat diterima untuk hostname pada URL. Service private yang menyajikan sertifikat bagi nama internal lain tidak akan memenuhi validasi sertifikat browser normal untuk hostname yang dikendalikan penyerang.

Kondisi ini membuat rebinding HTTPS-ke-HTTPS yang tidak terkait berbeda secara material dari kasus HTTP biasa. Kendali atas DNS saja tidak memberikan private key milik service tujuan kepada penyerang, dan validasi sertifikat tidak beralih memakai alamat IP hasil resolusi baru sebagai identitas DNS yang diminta.

Batasan tersebut bukan alasan untuk menganggap DNS rebinding sekadar artefak lama yang hanya terkait HTTP. Service lokal, development interface, endpoint administrasi perangkat, dan lingkungan deployment campuran masih dapat mengekspos HTTP biasa atau surface lain yang dapat diakses browser. Penilaian yang relevan harus mengikuti konfigurasi transport dan sertifikat yang benar-benar digunakan.

Pemeriksaan alamat jaringan memerlukan kebijakan resolusi yang jelas

Server yang menerima URL dari pengguna terkadang menangkal server-side request forgery dengan melakukan resolusi hostname lalu menolak alamat private. DNS rebinding menghadirkan persoalan desain yang terkait tetapi berbeda: alamat yang diperiksa pada satu waktu belum tentu menjadi alamat yang digunakan kemudian.

Prinsip yang sama berlaku ketika client atau proxy melakukan klasifikasi jaringan sebelum membuat koneksi. Keputusan yang aman memerlukan hubungan yang jelas antara validasi dan koneksi. Jika software memvalidasi satu hasil DNS lalu melakukan resolusi independen untuk koneksi sebenarnya, hasil kedua dapat berada di luar kumpulan alamat yang sudah divalidasi.

Desain yang mungkin dipakai antara lain membuat koneksi ke alamat hasil resolusi yang telah divalidasi sambil mempertahankan hostname yang dimaksud untuk identitas protokol, atau mengulang klasifikasi alamat untuk setiap alamat yang dapat dipilih. Mekanisme yang tepat bergantung pada networking API, jalur proxy, kebutuhan TLS, dan perilaku failover. Klasifikasi hostname satu kali tidak setara dengan membatasi tujuan socket yang akhirnya dipakai.

Proteksi jaringan browser merupakan layer kebijakan terpisah

Vendor browser dapat menegakkan pembatasan yang lebih kuat daripada same-origin policy klasik. Kontrol terhadap request dari konteks public menuju tujuan jaringan local atau private dapat menambahkan permission, preflight, atau blocking, bergantung pada browser dan status fiturnya.

Kontrol tersebut perlu diperlakukan sebagai layer enforcement tambahan, bukan dimasukkan ke definisi origin. Tuple origin dan klasifikasi jaringan tujuan menjawab pertanyaan yang berbeda. Perilaku deployment juga dapat berbeda antarversi browser dan konfigurasi kebijakan, sehingga aplikasi tidak semestinya menyimpulkan jaminan universal dari pengamatan pada satu client.

Pemisahan ini berguna secara operasional. Kontrol private-network di sisi browser dapat mengurangi paparan dari halaman berbahaya, sedangkan validasi authority dan autentikasi tetap melindungi service saat request datang melalui client lain atau konfigurasi browser dengan enforcement berbeda.

Autentikasi tetap menjadi batas service yang menentukan

DNS rebinding paling berdampak ketika service yang dapat dijangkau secara lokal memperlakukan reachability sebagai otorisasi. Request yang tiba dari browser pada mesin atau LAN yang sama dapat terlihat berasal dari jaringan lokal meski tindakan tersebut dipicu script yang dikendalikan penyerang.

Endpoint sensitif memerlukan keputusan otorisasi yang tetap berlaku saat provenance request berubah. Kredensial sesi, autentikasi API eksplisit, mekanisme anti-CSRF ketika kredensial browser ambient terlibat, serta kebijakan request-origin yang ketat menangani bagian persoalan yang berbeda. Tidak satu pun setara dengan sekadar listen pada alamat private.

Validasi Origin juga dapat memberi sinyal berguna untuk request perubahan state yang dimediasi browser, tetapi penerapannya bergantung pada tipe request dan perilaku service. Mekanisme ini bukan pengganti autentikasi, dan service tidak semestinya membuat fallback permisif saat header tersebut tidak ada.

Batas yang bertahan karena itu bukan stabilitas DNS. Batas tersebut adalah rangkaian pemeriksaan setelah koneksi mencapai service: authority yang diterima, principal yang terautentikasi, tindakan yang diotorisasi, serta kebijakan provenance request browser yang dibutuhkan aplikasi. DNS rebinding menyingkap sistem yang menyerahkan tanggung jawab tersebut hanya kepada topologi jaringan.