Wawancara Backend: Bagaimana Cara Mencegah SSRF pada Layanan Pengambil URL?

Konteks Soal dan Penerapan

Rancang alur pengambilan yang aman untuk API pratinjau URL. Pengguna terautentikasi mengirimkan URL HTTP atau HTTPS publik arbitrer. Pekerja latar belakang mengambil dokumen dan hanya mengembalikan judul halaman yang telah disanitasi. Produk tidak dapat mempertahankan daftar izin (allowlist) domain tetap karena situs web publik adalah input yang diharapkan.

Untuk wawancara ini, izinkan hanya port default 80 dan 443, ikuti maksimal tiga pengalihan, terapkan batas waktu total tiga detik, dan baca maksimal 2 MiB setelah dekompresi. Angka-angka ini adalah asumsi wawancara dan bukan pengaturan keamanan universal. Layanan tidak boleh menjangkau tujuan loopback, privat, bersama, link-local, multicast, dicadangkan, dokumentasi, atau metadata cloud melalui IPv4 atau IPv6. Layanan ini juga harus tahan terhadap notasi IP alternatif, jawaban DNS campuran, DNS rebinding, URL publik yang dialihkan ke alamat internal, respons berukuran terlalu besar, dan server yang lambat.

MITRE mendefinisikan CWE-918 sebagai server yang menerima URL dan mengambilnya tanpa memastikan secara memadai bahwa permintaan tersebut mencapai tujuan yang diharapkan. Kerangka berpikir tersebut sangat berguna: masalah intinya adalah otorisasi keluar (outbound authorization). Validasi input, perilaku DNS, rute jaringan, dan tujuan soket sebenarnya harus menerapkan satu kebijakan yang konsisten. Diskusi wawancara keamanan web publik tahun 2026 mencantumkan SSRF bersama XSS, SQL injection, dan IDOR sebagai topik yang harus siap dijelaskan oleh kandidat. Ini mendukung relevansi wawancara saat ini tetapi tidak menetapkan pertanyaan perusahaan yang pasti atau klaim frekuensi tertentu. OWASP Top 10:2025 memetakan CWE-918 ke dalam Broken Access Control, yang memperkuat model otorisasi ini.

Bank soal yang ada menyebutkan SSRF sebagai salah satu batasan dalam crawler dan pemendek URL. Pertanyaan ini mengisolasi alur pengambilan itu sendiri: penguraian, resolusi, klasifikasi tujuan, pengikatan koneksi, pengalihan, kontrol egress, dan bukti bahwa kebijakan tersebut bertahan terhadap kondisi time-of-check/time-of-use race.

Apa yang Dinilai oleh Pewawancara

Sinyal pertama adalah apakah kandidat memodelkan tujuan sebagai keputusan otorisasi. Pemeriksaan terhadap string localhost dan 127.0.0.1 tidaklah lengkap. Tujuan dapat berupa literal IPv6, alamat IPv6 yang dipetakan ke IPv4, representasi numerik alternatif, nama host dengan jawaban aman dan tidak aman sekaligus, target pengalihan, atau nama yang jawaban DNS-nya berubah antara validasi dan koneksi.

Sinyal kedua adalah kedisiplinan parser. Pemeriksaan regex dan substring tidak mendefinisikan semantik URL. Jawaban yang kuat menggunakan satu parser berbasis standar, menolak kegagalan penguraian dan kredensial yang disematkan, hanya mengizinkan skema HTTP eksplisit dan port yang diharapkan, lalu membuat semua keputusan kebijakan dari kolom kanonikal parser. Verifikasi TLS tetap menggunakan nama host normalisasi asli bahkan ketika soket di-pin ke alamat IP yang telah diperiksa.

Sinyal ketiga adalah menutup celah DNS rebinding. Menyelesaikan dan menyetujui IP tidak efektif jika pustaka HTTP melakukan pencarian DNS kedua sebelum membuka soket. Pengambil harus terhubung ke alamat yang disetujui secara spesifik, atau mengirim permintaan melalui proksi egress sadar-kebijakan yang melakukannya. Setiap pengalihan dan percobaan ulang adalah peristiwa otorisasi baru.

Sinyal keempat adalah pertahanan berlapis (defense in depth). Bug aplikasi harus bertemu dengan batasan jaringan yang tidak dapat merutekan ke subnet internal atau endpoint metadata. Pekerja harus memiliki hak istimewa identitas minimal, tidak memiliki cookie pengguna atau header otorisasi bawaan, parser yang berbatas, dan tidak memiliki kemampuan untuk mengeksekusi skrip halaman atau mengambil sub-sumber daya.

Sinyal terakhir adalah validasi yang dapat dibuktikan salah (falsifiable validation). Kandidat harus mengusulkan pengujian yang melatih bentuk alamat alternatif, rekaman A dan AAAA campuran, perlombaan resolusi ulang, pengalihan, batas dekompresi, dan aturan firewall egress. Mengatakan "gunakan allowlist" tidak menyelesaikan masalah ini karena domain publik arbitrer adalah persyaratan produk; itu hanya tepat untuk cakupan mitra khusus yang berbeda.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Apakah tujuannya adalah situs publik arbitrer atau mitra yang dikenal? Mitra yang dikenal

memungkinkan allowlist skema-host-port yang tepat. Pratinjau arbitrer memerlukan kebijakan alamat publik yang konservatif dan batasan egress yang ditegakkan jaringan.

• Protokol, port, metode, dan header apa yang diperlukan? Permintaan ini hanya mengizinkan GET

melalui HTTP pada port 80 atau HTTPS pada port 443. Layanan ini tidak menerima metode yang dipilih pemanggil, body permintaan, proksi, cookie, header otorisasi, atau header arbitrer.

• Apakah pengalihan diperlukan? Ya, hingga tiga hop. Layanan menonaktifkan pengalihan otomatis

dan mengotorisasi setiap target Location secara independen sebelum mengikutinya.

• Output apa yang dibutuhkan? Hanya judul yang disanitasi. Pekerja tidak mengembalikan HTML mentah,

mengeksekusi JavaScript, memproses entitas eksternal XML, merender gambar, atau mengambil stylesheet, font, atau skrip.

• Ruang alamat apa yang dapat dijangkau dari pekerja? Jawabannya harus mencakup IPv4, IPv6, rute

jaringan kontainer dan layanan, jaringan korporat, dan endpoint metadata penyedia. Inventarisasi diperlukan sebelum kebijakan egress dapat diuji.

• Bagaimana perilaku cache dan percobaan ulang? Pratinjau yang di-cache dapat mengurangi pengambilan

berulang, tetapi kegagalan cache (cache miss) tetap melintasi jalur yang aman. Desain ini tidak mencoba ulang secara otomatis. Percobaan ulang eksplisit mengulangi resolusi DNS, otorisasi, dan connection pinning dari awal.

• Kompromi ketersediaan apa yang dapat diterima? Menolak nama host ketika salah satu alamat yang

dikembalikan tidak aman dapat memblokir situs publik yang salah dikonfigurasi. Permintaan ini memilih keamanan daripada keterjangkauan parsial; penolakan ini dapat diamati dan tidak secara diam-diam memilih jawaban lain.

Kerangka Jawaban 30 Detik

"Saya akan mengurai dengan parser URL berbasis standar, hanya mengizinkan HTTP pada port 80 atau HTTPS pada port 443, dan menolak kredensial. Saya akan menyelesaikan setiap jawaban A dan AAAA melalui resolver tepercaya, menormalkan IPv6 yang dipetakan ke IPv4, dan menolak tujuan jika ada alamat yang berada di luar kebijakan alamat publik yang dikelola. Pekerja terhubung langsung ke satu IP yang disetujui tetapi mempertahankan nama host untuk Host, TLS SNI, dan verifikasi sertifikat, sehingga menutup celah DNS rebinding. Pengalihan dan percobaan ulang otomatis tetap dinonaktifkan; setiap pengalihan mengulangi pemeriksaan lengkap. Firewall egress yang terisolasi memblokir rute internal dan metadata. Saya kemudian menerapkan batas tiga detik, 2 MiB, dan tiga hop, tidak memuat sub-sumber daya, serta menguji rebinding dan pengalihan ke metadata secara menyeluruh."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Ubah persyaratan menjadi satu kebijakan tujuan

Representasikan kebijakan secara eksplisit alih-alih menyebarkan pemeriksaan string ke seluruh API, pekerja, dan klien HTTP:

DestinationPolicy
  schemes: http, https
  origin_pairs: http:80, https:443
  userinfo: forbidden
  address_requirement: globally reachable public unicast
  redirects: at most 3, authorize every hop
  method: GET
  caller_headers: none
  total_deadline: 3 seconds
  decompressed_body_limit: 2 MiB

API mengautentikasi pemanggil, menerapkan kuota akun dan tenant, menyimpan string yang dikirimkan sebagai data yang tidak tepercaya, dan mengantrekan tugas. API tidak melakukan "pemeriksaan keamanan" lalu meneruskan flag tepercaya ke pekerja berikutnya; DNS dan rute dapat berubah sebelum tugas dijalankan. Pekerja adalah komponen yang membuka koneksi, sehingga ia membuat keputusan otoritatif tepat sebelum menghubungkan.

Untuk integrasi mitra, kebijakan terkuat adalah allowlist tepat dari skema, nama host, dan port yang dinormalisasi, secara opsional dengan jalur yang diharapkan. Produk pratinjau ini sengaja menerima host publik arbitrer. Oleh karena itu, kebijakannya hanya mengizinkan tujuan yang diklasifikasikan sebagai publik dan dapat dijangkau secara global. Pertahankan pengklasifikasi dari registri alamat otoritatif dan inventarisasi jaringan organisasi itu sendiri. Daftar yang ditulis manual yang hanya berisi rentang RFC 1918 akan melewatkan loopback, link-local, bersama, multicast, dicadangkan, dokumentasi, unique-local IPv6, bentuk IPv4-mapped, dan endpoint metadata khusus penyedia.

Langkah 2: Urai terlebih dahulu dan buat keputusan kebijakan dari kolom yang diurai

Gunakan parser URL yang kompatibel dengan WHATWG atau yang teruji dengan baik di platform tersebut. Wajibkan URL absolut. Tolak kesalahan penguraian, komponen nama pengguna atau kata sandi, fragmen jika produk tidak memiliki alasan untuk menyimpannya, skema non-HTTP, dan port di luar kebijakan eksplisit. Normalkan nama host melalui parser, termasuk nama yang diinternasionalkan, dan jangan pernah menginterpretasikan ulang string mentah secara terpisah dengan regex.

Contoh seperti https://expected.example@evil.example/ menunjukkan mengapa pencocokan awalan tidak aman: host jaringan sebenarnya adalah evil.example. Fragmen tidak memilih tujuan jaringan, dan pengodean atau bentuk numerik alternatif dapat menciptakan ketidaksesuaian antara validator dan klien HTTP. Satu parser harus menyediakan skema, host kanonikal, port efektif, dan jalur permintaan yang digunakan oleh setiap langkah selanjutnya.

Jika host berupa literal IP, kanonisasikan dan klasifikasikan segera. Konversikan IPv6 yang dipetakan ke IPv4 ke nilai IPv4 yang disematkan sebelum menerapkan kebijakan kedua keluarga alamat tersebut. Jangan menyimpulkan keamanan dari tanda baca, panjang string, atau apakah host "terlihat seperti" domain.

Langkah 3: Selesaikan setiap alamat dan ikat koneksi ke hasil yang disetujui

Untuk nama host, selesaikan rekaman A dan AAAA dengan resolver yang terkontrol. Ikuti pemrosesan CNAME normal resolver dan kumpulkan alamat akhir. Permintaan ini menolak tujuan jika ada jawaban yang tidak diizinkan. Setiap alamat melewati pengklasifikasi yang sama dengan literal IP. Catat kode alasan, bukan URL lengkap yang memuat kueri, saat menolaknya.

Invarian pentingnya adalah:

the IP authorized by policy == the IP used by connect()

Pilih satu alamat yang disetujui dan berikan alamat persis tersebut ke lapisan soket. Pertahankan nama host yang dinormalisasi untuk header Host HTTP dan, untuk HTTPS, TLS SNI dan verifikasi nama host sertifikat. Sertifikat yang valid untuk IP numerik bukanlah pengganti. Nonaktifkan pencarian DNS independen klien HTTP; jika tidak, penyerang dapat mengembalikan alamat publik selama validasi dan alamat privat selama koneksi.

Proksi egress sadar-kebijakan dapat menangani resolusi, klasifikasi, dan connection pinning alih-alih dilakukan oleh setiap pekerja. Pekerja mengirimkan URL yang dinormalisasi dan kebijakan permintaan tetap ke proksi tersebut, bukan ke alamat proksi yang dipilih penyerang. Komponen yang sama harus membuat keputusan otorisasi dan soket, atau meneruskan hasil alamat yang disetujui yang tahan manipulasi melintasi batas yang dikontrol secara ketat.

Jawaban DNS dapat berotasi secara sah, sehingga pinning hanya berlangsung untuk satu hop pengambilan, tidak selamanya. Tugas berikutnya, pengalihan, atau percobaan ulang eksplisit akan menyelesaikan dan mengotorisasi kembali. Connection pooling harus diberi kunci berdasarkan origin dan kebijakan yang diotorisasi; jangan pernah menggunakan kembali soket hanya karena string URL yang tidak tepercaya tampak serupa.

Langkah 4: Perlakukan setiap pengalihan sebagai permintaan keluar baru

Matikan pengikutan pengalihan otomatis. Untuk setiap respons dengan status pengalihan, selesaikan Location terhadap URL saat ini menggunakan parser yang sama, tingkatkan jumlah hop, dan mulai ulang pemeriksaan skema, port, userinfo, DNS, alamat, dan koneksi. Tolak lokasi yang hilang atau salah format, perulangan, pengalihan keempat, dan hop mana pun yang diselesaikan ke alamat yang tidak diizinkan.

Jangan meneruskan cookie pemanggil, header otorisasi, atau header arbitrer ke host pertama. Jangan meneruskan kredensial yang disetel respons ke origin yang berbeda. Pengambil menggunakan User-Agent tetap dan sekumpulan header tetap yang minimal. Karena produk hanya membutuhkan judul, GET sudah cukup; pengalihan tidak boleh mengubah operasi menjadi POST dengan body yang dikontrol pemanggil.

Ini menutup celah umum: URL publik yang dikontrol penyerang mengembalikan pengalihan ke http://169.254.169.254/, http://127.0.0.1/, atau layanan internal. Menyetujui hanya URL pertama akan mengotorisasi tujuan akhir yang berbeda dari yang sebenarnya dihubungi.

Langkah 5: Buat jaringan menolak apa yang terlewatkan oleh kode aplikasi

Jalankan pekerja pengambil di segmen jaringan atau namespace khusus. Firewall egress-nya hanya mengizinkan DNS ke resolver yang terkontrol dan HTTP/HTTPS hanya melalui proksi sadar-kebijakan atau rute publik yang disetujui. Ini menolak celah loopback, rentang layanan internal, jaringan kluster, jaringan korporat, ruang link-local, dan endpoint metadata cloud untuk kedua keluarga IP. Validasi rute efektif, bukan hanya aturan tertulis.

Identitas layanan pekerja hanya memiliki izin yang diperlukan untuk membaca dan menyelesaikan tugas pratinjau. Hindari menempatkan kredensial cloud yang luas di lingkungannya. Pada EC2, menonaktifkan metadata instans saat tidak digunakan atau mewajibkan IMDSv2 mengurangi paparan; AWS mendokumentasikan endpoint metadata IPv4 169.254.169.254 dan endpoint IPv6 opsional. Kontrol ini menambahkan pertahanan berlapis dan tidak membuat kebijakan URL menjadi opsional.

Gunakan pool pekerja terpisah dari klien webhook internal atau administrasi. Pembantu HTTP generik yang dapat menjangkau layanan privat tidak boleh memproses URL yang tidak tepercaya. Upaya yang ditolak jaringan, termasuk tujuan metadata, harus menghasilkan metrik dan peringatan tanpa mengekspos topologi internal kepada pemanggil.

Langkah 6: Batasi pengambilan dan urai hanya artefak yang dijanjikan

Terapkan tenggat waktu terpisah untuk DNS, koneksi, byte pertama, pembacaan diam, dan total tiga detik. Lakukan streaming pada respons dan hentikan setelah 2 MiB konten yang didekompresi; batas body terkompresi saja memungkinkan terjadinya decompression bomb. Terima hanya tipe konten yang diperlukan untuk judul HTML. Batasi konkurensi per akun dan secara global sehingga banyak server publik yang lambat tidak dapat menghabiskan semua pekerja.

Jangan mencoba ulang secara otomatis. Percobaan ulang membuat otorisasi keluar lainnya dan dapat melipatgandakan beban. Jika persyaratan produk nantinya menambahkan percobaan ulang, setiap upaya dimulai dari penguraian dan resolusi serta tetap berada di dalam total batas waktu tugas.

Parser memperlakukan body sebagai ancaman (hostile). Parser tidak mengeksekusi JavaScript, menyelesaikan entitas eksternal XML, memuat gambar, stylesheet, font, iframe, atau skrip, atau mengikuti instruksi penyegaran metadata. Ekstrak judul dengan streaming terbatas atau parser terisolasi, normalkan sebagai teks, batasi panjangnya, dan kembalikan hanya nilai tersebut. Jauhkan HTML mentah dari respons API dan lakukan escape pada judul di tempat rendering akhir.

Langkah 7: Amati keputusan dan uji invarian tingkat soket

Catat hasil tugas, host yang dinormalisasi atau kunci host yang menjaga privasi, skema, port efektif, kelas alamat yang dipilih, jumlah pengalihan, byte, durasi, dan alasan penolakan yang stabil. Jangan mencatat URL lengkap, query string, userinfo, body respons, atau payload DNS karena URL dapat memuat rahasia. Lacak tingkat penolakan untuk aturan privat, link-local, metadata, skema, port, pengalihan, ukuran, batas waktu, dan tipe konten.

Uji melalui resolver, proksi, firewall, dan klien HTTP yang sebenarnya. Sertakan:

• varian loopback seperti 127.1, IPv6 ::1, dan IPv6 yang dipetakan ke IPv4;
• alamat privat, bersama, link-local, multicast, dicadangkan, dokumentasi, dan metadata;
• domain dengan satu jawaban publik dan satu privat, ditambah rekaman A dan AAAA;
• resolver yang mengembalikan publik selama validasi dan privat pada pencarian berikutnya;
• endpoint publik yang mengalihkan ke setiap keluarga alamat yang ditolak dan endpoint yang melakukan

perulangan empat kali;

• kredensial yang disematkan, host yang dikodekan, skema non-HTTP, port terlarang, dan URL salah format;
• header lambat, body tertahan, body terdekompresi berukuran besar, dan bom kompresi;
• halaman HTML yang skrip atau gambarnya mengarah ke host internal;
• halaman HTTPS publik yang valid yang soketnya di-pin sementara TLS memverifikasi nama host asli;
• bypass kebijakan aplikasi yang disengaja yang tetap diblokir oleh firewall egress.

Pengujian DNS-rebinding harus gagal jika klien melakukan pencarian kedua. Pengujian TLS positif harus gagal jika verifikasi sertifikat secara tidak sengaja menargetkan IP numerik. Bersama-sama, keduanya membuktikan bahwa validasi dan koneksi menggunakan identitas yang dimaksudkan.

Contoh Jawaban Berkualitas Tinggi

"Saya akan memodelkan pencegahan SSRF sebagai otorisasi keluar yang dilakukan oleh komponen yang membuka soket. API mengautentikasi dan membatasi laju pemanggil, menyimpan URL sebagai input yang tidak tepercaya, dan mengantrekan tugas. Pekerja pengambil menguraikannya dengan parser berbasis standar, menolak userinfo, skema non-HTTP, dan port di luar 80 dan 443, serta mengambil host dan jalur kanonikal hanya dari parser tersebut.

Untuk literal IP, saya menganonisasikannya, membuka bungkus IPv6 yang dipetakan ke IPv4, dan menerapkan pengklasifikasi alamat publik yang dikelola. Untuk nama host, saya menyelesaikan semua jawaban A dan AAAA melalui resolver yang terkontrol dan menolak seluruh tujuan jika ada hasil yang berupa privat, loopback, bersama, link-local, multicast, dicadangkan, dokumentasi, metadata, atau di luar kebijakan. Saya kemudian terhubung ke satu IP yang disetujui secara langsung sambil mempertahankan nama host asli untuk Host, TLS SNI, dan verifikasi sertifikat. Itu menghilangkan celah pencarian DNS kedua yang digunakan oleh serangan rebinding.

Pengalihan dan percobaan ulang otomatis dinonaktifkan. Hingga tiga pengalihan, saya mengurai lokasi baru dan mengulangi otorisasi lengkap sebelum membuka soket lain. Saya hanya mengirim GET dengan header tetap dan tanpa cookie atau kredensial pemanggil. Proksi egress atau firewall khusus secara terpisah menolak setiap rute internal, kluster, korporat, link-local, dan metadata melalui IPv4 dan IPv6. Pekerja memiliki identitas layanan minimal dan tidak dapat menggunakan klien HTTP internal umum.

Setiap tugas memiliki batas waktu total tiga detik dan batas body terdekompresi 2 MiB. Parser tidak mengeksekusi skrip dan tidak memuat sub-sumber daya; parser hanya mengembalikan judul yang disanitasi dan dibatasi panjangnya. Saya mencatat kode alasan, kelas alamat, jumlah pengalihan, byte, dan latensi tanpa URL lengkap. Rangkaian penerimaan saya mencakup jawaban DNS campuran, rebinding antara pemeriksaan dan koneksi, IPv6 yang dipetakan ke IPv4, pengalihan ke metadata, bom gzip, body lambat, TLS dengan pinning soket, dan bypass kebijakan yang harus tetap dihentikan oleh jaringan."

Kesalahan Umum

• Hanya memblokir localhost dan RFC 1918 → bentuk IPv4 alternatif, IPv6, link-local, bersama,

dicadangkan, dan alamat metadata tetap dapat dijangkau → **kanonisasikan dan klasifikasikan kedua keluarga alamat dengan kebijakan tujuan publik yang dikelola.**

• Memvalidasi dengan regex → validator dan parser HTTP dapat tidak sepakat tentang kredensial,

pengodean, host, dan port → **gunakan satu parser berbasis standar dan gunakan hanya kolom kanonikalnya.**

• Menyelesaikan, memeriksa, lalu membiarkan klien menyelesaikan lagi → DNS rebinding mengubah

tujuan soket setelah persetujuan → **pin koneksi ke IP yang telah diperiksa sambil memverifikasi TLS terhadap nama host.**

• Hanya menyetujui URL pertama → host publik yang diizinkan dapat mengalihkan ke layanan internal →

nonaktifkan pengalihan otomatis dan otorisasi ulang setiap hop.

• Memilih jawaban aman dari hasil DNS campuran → perubahan pemilihan alamat nantinya dapat

menjangkau jawaban yang tidak aman → **tolak nama host jika ada alamat yang dikembalikan melanggar kebijakan permintaan ini.**

• Meneruskan header pemanggil → cookie atau nilai otorisasi bocor ke host yang dipilih penyerang →

buat permintaan keluar tetap tanpa kredensial bawaan.

• Hanya mengandalkan IMDSv2 atau pengaturan cloud → layanan internal dan rentang alamat lain tetap

terekspos → **gabungkan otorisasi aplikasi, identitas minimal, penguatan metadata, dan penolakan egress.**

• Hanya membatasi byte terkompresi → body kecil dapat mengembang hingga memori atau CPU habis →

batasi byte terdekompresi, kerja penguraian, waktu, dan konkurensi.

• Mengurai halaman seperti browser → skrip dan sub-sumber daya membuat permintaan keluar baru yang

tidak ditinjau → **ekstrak hanya artefak yang dijanjikan dengan konten aktif dan resolusi entitas eksternal dinonaktifkan.**

• Mencatat URL lengkap untuk debugging → rahasia kueri dan kredensial berpindah ke sistem

observabilitas → catat kolom kanonikal terbatas dan kode alasan yang stabil.

Pertanyaan Lanjutan

Apa yang berubah jika setiap tujuan adalah mitra yang dikenal?

Gunakan allowlist tepat dari skema, nama host, dan port yang dinormalisasi dan sediakan melalui konfigurasi yang telah ditinjau. Selesaikan dan klasifikasikan alamatnya: rekaman DNS yang disusupi atau kesalahan konfigurasi tidak boleh mengubah nama tepercaya menjadi rute internal. Endpoint mitra privat termasuk dalam integrasi terautentikasi terpisah dengan jalur jaringan eksplisit, bukan di pekerja pratinjau publik.

Bisakah layanan mendukung pengalihan lintas domain dengan aman?

Ya, jika pengalihan lintas domain adalah persyaratan produk dan setiap hop mengulangi seluruh kebijakan. Hapus kredensial dan status khusus origin, selesaikan nama host baru, klasifikasikan setiap hasil, pin koneksi baru, dan hitung hop-nya. Kebijakan yang lebih sederhana dapat mewajibkan origin yang sama, tetapi ini akan menolak pengalih publik umum; pewawancara harus mendengar kompromi produk tersebut secara eksplisit.

Mengapa menolak nama host jika satu jawaban DNS bersifat publik dan yang lain privat?

Ini menciptakan kontrak fail-closed yang stabil. Pengurutan alamat bervariasi di seluruh resolver, keluarga IP, dan percobaan ulang. Memilih satu jawaban publik selama validasi sementara komponen lain nantinya memilih jawaban privat akan membuka kembali celah tersebut. Produk yang menginginkan penerimaan parsial membutuhkan komponen yang sama untuk mem-pin hanya alamat yang disetujui untuk setiap koneksi dan harus menguji failover secara hati-hati; permintaan ini mengambil kebijakan konservatif yang lebih sederhana.

Bagaimana jika produk membutuhkan tangkapan layar atau pratinjau yang dirender JavaScript?

Tempatkan perenderan di tingkat yang lebih terisolasi dengan kebijakan egress yang sama. Browser membuat banyak permintaan sekunder, jadi cegat dan otorisasi setiap navigasi, pengalihan, pekerja, WebSocket, dan sub-sumber daya. Nonaktifkan akses file lokal dan fitur browser yang tidak perlu, batasi CPU, memori, waktu, dan unduhan, serta hancurkan sandbox setelah setiap tugas. Perenderan tidak mewarisi kepercayaan dari URL halaman awal.

Bagaimana Anda membuktikan bahwa firewall efektif setelah penerapan?

Jalankan canary terkontrol dari identitas dan namespace pekerja sebenarnya terhadap tujuan IPv4, IPv6, kluster, korporat, dan metadata yang ditolak, lalu konfirmasikan kegagalan koneksi dan telemetri jaringan yang diharapkan. Ulangi setelah perubahan rute, kontainer, proksi, atau jaringan cloud. Tinjauan konfigurasi menunjukkan niat; canary dan log aliran (flow logs) menunjukkan jalur yang sebenarnya.