Temu Duga Backend: Bagaimanakah Anda Mencegah SSRF dalam Perkhidmatan Mengambil URL?

Gesaan dan Konteks yang Berkenaan

Reka bentuk laluan pengambilan selamat untuk API pratonton URL. Pengguna yang disahkan menyerahkan sebarang URL HTTP atau HTTPS awam. Pekerja latar belakang mengambil dokumen tersebut dan hanya mengembalikan tajuk halaman yang telah disanitasi. Produk ini tidak boleh mengekalkan senarai putih (allowlist) domain yang tetap kerana laman web awam merupakan input yang dimaksudkan.

Untuk temu duga ini, benarkan hanya port lalai 80 dan 443, ikuti paling banyak tiga lencongan, kuat kuasakan batas masa keseluruhan tiga saat, dan baca paling banyak 2 MiB selepas penyahmampatan. Angka-angka ini merupakan andaian temu duga dan bukannya tetapan keselamatan universal. Perkhidmatan ini tidak boleh mencapai destinasi gelung balik, peribadi, dikongsi, pautan-tempatan, multisiar, dikhaskan, dokumentasi, atau metadata awan melalui IPv4 atau IPv6. Ia juga mesti tahan terhadap tatatanda IP alternatif, jawapan DNS bercampur, pengikatan semula DNS, URL awam yang melencong ke alamat dalaman, respons bersaiz lampau, dan pelayan yang perlahan.

MITRE mentakrifkan CWE-918 sebagai pelayan yang menerima URL dan mendapatkannya semula tanpa memastikan secukupnya bahawa permintaan tersebut mencapai destinasi yang dijangkakan. Rangka kerja itu berguna: masalah terasnya ialah kebenaran keluar (outbound authorization). Pengesahan input, tingkah laku DNS, laluan rangkaian, dan destinasi soket sebenar mesti menguatkuasakan satu dasar yang sama. Perbincangan temu duga keselamatan web 2026 awam menyenaraikan SSRF bersama XSS, suntikan SQL, dan IDOR sebagai topik yang perlu bersedia diterangkan oleh calon. Ini menyokong kerelevanan temu duga semasa tetapi tidak menetapkan soalan syarikat yang tetap atau tuntutan kekerapan. OWASP Top 10:2025 memetakan CWE-918 ke dalam Broken Access Control, mengukuhkan model kebenaran tersebut.

Bank soalan sedia ada menyebut SSRF sebagai satu sempadan dalam perangkak (crawler) dan pemendek URL. Soalan ini mengasingkan laluan pengambilan itu sendiri: penghuraian, resolusi, pengelasan destinasi, pengikatan sambungan, lencongan, kawalan egress, dan bukti bahawa dasar tersebut bertahan daripada perlumbaan time-of-check/time-of-use (TOCTOU).

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon memodelkan destinasi sebagai keputusan kebenaran. Pemeriksaan terhadap rentetan localhost dan 127.0.0.1 adalah tidak lengkap. Destinasi mungkin merupakan literal IPv6, alamat IPv6 yang dipetakan IPv4, perwakilan numerik alternatif, nama hos dengan jawapan selamat dan tidak selamat, sasaran lencongan, atau nama yang jawapan DNS-nya berubah antara pengesahan dan sambungan.

Isyarat kedua ialah disiplin penghurai (parser). Pemeriksaan regex dan subrentetan tidak mentakrifkan semantik URL. Jawapan yang kukuh menggunakan satu penghurai berasaskan piawaian, menolak kegagalan penghuraian dan kelayakan terbina dalam, hanya membenarkan skema HTTP eksplisit dan port yang dijangkakan, dan kemudian membuat semua keputusan dasar daripada medan kanonikal penghurai tersebut. Pengesahan TLS masih menggunakan nama hos ternormal yang asal walaupun soket dipin (pinned) pada alamat IP yang telah diperiksa.

Isyarat ketiga ialah menutup jurang pengikatan semula DNS (DNS rebinding). Menyelesaikan dan meluluskan IP adalah tidak berkesan apabila pustaka HTTP melakukan carian DNS kedua sebelum membuka soket. Pengambil (fetcher) mesti menyambung ke alamat diluluskan yang khusus, atau menghantar permintaan melalui proksi egress peka-dasar yang berbuat demikian. Setiap lencongan dan percubaan semula ialah peristiwa kebenaran baharu.

Isyarat keempat ialah pertahanan secara mendalam (defense in depth). Pepijat aplikasi sepatutnya terhalang oleh sempadan rangkaian yang tidak boleh menghalakan trafik ke subnet dalaman atau titik akhir metadata. Pekerja harus mempunyai keistimewaan identiti yang minimum, tiada kuki pengguna atau pengepala kebenaran sekitaran (ambient), penghurai terhad, dan tiada keupayaan untuk melaksanakan skrip halaman atau mengambil sub-sumber.

Isyarat terakhir ialah pengesahan yang boleh difalsifikasi. Calon harus mencadangkan ujian yang menguji bentuk alamat alternatif, rekod A dan AAAA bercampur, perlumbaan resolusi semula, lencongan, had penyahmampatan, dan peraturan tembok api egress. Mengatakan "gunakan senarai putih" tidak menyelesaikan gesaan ini kerana domain awam rawak merupakan keperluan produk; ia hanya sesuai untuk skop rakan kongsi sahaja yang berbeza.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah destinasi merupakan laman awam rawak atau rakan kongsi yang diketahui? Rakan kongsi yang diketahui membenarkan

senarai putih skema-hos-port yang tepat. Pratonton rawak memerlukan dasar alamat awam yang konservatif dan sempadan egress yang dikuatkuasakan rangkaian.

• Apakah protokol, port, kaedah, dan pengepala yang diperlukan? Gesaan ini hanya membenarkan GET melalui

HTTP pada port 80 atau HTTPS pada port 443. Ia tidak menerima kaedah pilihan pemanggil, jasad permintaan, proksi, kuki, pengepala kebenaran, atau pengepala sebarangan.

• Adakah lencongan diperlukan? Ya, sehingga tiga lompatan (hops). Perkhidmatan menyahdayakan lencongan automatik dan

memberi kebenaran secara bebas kepada setiap sasaran Location sebelum mengikutinya.

• Apakah output yang diperlukan? Hanya tajuk yang telah disanitasi. Pekerja tidak mengembalikan HTML mentah, melaksanakan

JavaScript, memproses entiti luaran XML, merender imej, atau mengambil lembaran gaya, fon, atau skrip.

• Apakah ruang alamat yang boleh dicapai daripada pekerja? Jawapan mesti merangkumi IPv4, IPv6, laluan

rangkaian kontena dan perkhidmatan, rangkaian korporat, dan titik akhir metadata penyedia. Inventori diperlukan sebelum dasar egress boleh diuji.

• Bagaimanakah cache dan percubaan semula harus bertindak? Pratonton yang dicache boleh mengurangkan pengambilan berulang, tetapi kegagalan

cache (cache miss) masih merentasi laluan selamat. Reka bentuk ini tidak mencuba semula secara automatik. Percubaan semula eksplisit mengulangi resolusi DNS, kebenaran, dan penetapan sambungan dari awal.

• Apakah kompromi ketersediaan yang boleh diterima? Menolak nama hos apabila mana-mana alamat yang dikembalikan adalah

tidak selamat boleh menyekat laman awam yang salah dikonfigurasikan. Gesaan ini memilih keselamatan berbanding kebolehcapaian separa; penolakan tersebut boleh dicerap dan tidak memilih jawapan lain secara senyap.

Rangka Kerja Jawapan 30 Saat

“Saya akan menghurai dengan penghurai URL berasaskan piawaian, membenarkan hanya HTTP pada port 80 atau HTTPS pada port 443, dan menolak kelayakan. Saya akan menyelesaikan setiap jawapan A dan AAAA melalui penyelesai yang dipercayai, menormalkan IPv6 yang dipetakan IPv4, dan menolak destinasi jika mana-mana alamat berada di luar dasar alamat awam yang diselenggara. Pekerja menyambung secara terus ke satu IP yang diluluskan tetapi mengekalkan nama hos untuk Host, TLS SNI, dan pengesahan sijil, sekali gus menutup jurang pengikatan semula DNS. Lencongan dan percubaan semula automatik kekal dinyahdayakan; setiap lencongan mengulangi pemeriksaan penuh. Tembok api egress yang diasingkan menyekat laluan dalaman dan metadata. Saya kemudiannya menguatkuasakan had tiga saat, 2 MiB, dan tiga lompatan, tidak memuatkan sebarang sub-sumber, dan menguji pengikatan semula serta lencongan-ke-metadata secara menyeluruh (end to end).”

Perbincangan Terperinci Langkah Demi Langkah

Langkah 1: Tukar keperluan menjadi satu dasar destinasi

Wakilkan dasar secara eksplisit dan bukannya mengagihkan pemeriksaan rentetan merentasi 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 mengesahkan pemanggil, menggunakan kuota akaun dan penyewa, menyimpan rentetan yang diserahkan sebagai data yang tidak dipercayai, dan mengatur giliran kerja. Ia tidak melakukan “pemeriksaan keselamatan” dan menghantar bendera dipercayai kepada pekerja kemudian; DNS dan laluan boleh berubah sebelum kerja dijalankan. Pekerja ialah komponen yang membuka sambungan, jadi ia membuat keputusan berwibawa sejurus sebelum menyambung.

Untuk penyepaduan rakan kongsi, dasar yang paling kukuh ialah senarai putih tepat bagi skema, nama hos, dan port yang dinormalkan, secara pilihan dengan laluan yang dijangkakan. Produk pratonton ini secara sengaja menerima hos awam rawak. Oleh itu, dasarnya hanya membenarkan destinasi yang dikelaskan sebagai awam dan boleh dicapai secara global. Selenggara pengelas daripada pendaftar alamat berwibawa dan inventori rangkaian organisasi itu sendiri. Senarai yang ditulis secara manual yang hanya mengandungi julat RFC 1918 akan terlepas gelung balik, pautan-tempatan, dikongsi, multisiar, dikhaskan, dokumentasi, unik-tempatan IPv6, bentuk pemetaan IPv4, dan titik akhir metadata khusus penyedia.

Langkah 2: Hurai dahulu dan buat keputusan dasar daripada medan yang dihuraikan

Gunakan penghurai URL platform yang serasi dengan WHATWG atau yang diuji dengan baik setaraf dengannya. Wajibkan URL mutlak. Tolak ralat penghuraian, komponen nama pengguna atau kata laluan, serpihan (fragments) jika produk tiada sebab untuk menyimpannya, skema bukan HTTP, dan port di luar dasar eksplisit. Normalkan nama hos melalui penghurai, termasuk nama yang diantarabangsakan, dan jangan sekali-kali mentafsir semula rentetan mentah secara berasingan dengan regex.

Contoh seperti https://expected.example@evil.example/ menunjukkan sebab pemadanan awalan tidak selamat: hos rangkaiannya ialah evil.example. Serpihan tidak memilih destinasi rangkaian, dan pengekodan atau bentuk numerik alternatif boleh mewujudkan percanggahan antara pengesah dan klien HTTP. Satu penghurai mesti membekalkan skema, hos kanonikal, port efektif, dan laluan permintaan yang digunakan oleh setiap langkah seterusnya.

Jika hos ialah literal IP, kanonikalkan dan kelaskannya serta-merta. Tukar IPv6 yang dipetakan IPv4 kepada nilai IPv4 terbenamnya sebelum menggunakan dasar kedua-dua keluarga alamat. Jangan membuat kesimpulan tentang keselamatan daripada tanda baca, panjang rentetan, atau sama ada hos “kelihatan seperti” domain.

Langkah 3: Selesaikan setiap alamat dan ikat sambungan pada hasil yang diluluskan

Untuk nama hos, selesaikan kedua-dua rekod A dan AAAA dengan penyelesai terkawal. Ikuti pemprosesan CNAME biasa penyelesai dan kumpulkan alamat akhir. Gesaan ini menolak destinasi jika mana-mana jawapan tidak dibenarkan. Setiap alamat melalui pengelas yang sama seperti literal IP. Catatkan kod sebab, bukan URL penuh yang mengandungi pertanyaan (query), apabila menolaknya.

Invarian kritikalnya ialah:

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

Pilih satu alamat yang diluluskan dan berikan alamat tepat itu kepada lapisan soket. Kekalkan nama hos yang dinormalkan untuk pengepala HTTP Host dan, untuk HTTPS, TLS SNI dan pengesahan nama hos sijil. Sijil yang sah untuk IP numerik bukanlah pengganti. Nyahdayakan carian DNS bebas klien HTTP; jika tidak, penyerang boleh mengembalikan alamat awam semasa pengesahan dan alamat peribadi semasa sambungan.

Proksi egress peka-dasar boleh mengambil alih resolusi, pengelasan, dan penetapan sambungan dan bukannya dilakukan oleh setiap pekerja. Pekerja menghantar URL ternormal dan dasar permintaan tetap kepada proksi tersebut, bukan alamat proksi pilihan penyerang. Komponen yang sama mesti membuat keputusan kebenaran dan soket, atau menghantar hasil alamat diluluskan yang kalis usikan merentasi sempadan yang dikawal ketat.

Jawapan DNS mungkin berputar secara sah, jadi penetapan hanya bertahan untuk satu lompatan pengambilan, bukan selama-lamanya. Kerja, lencongan, atau percubaan semula eksplisit yang kemudian akan menyelesaikan dan memberi kebenaran semula. Penyatuan sambungan (connection pooling) mesti menggunakan kunci asal dan dasar yang dibenarkan; jangan sekali-kali menggunakan semula soket semata-mata kerana rentetan URL yang tidak dipercayai kelihatan serupa.

Langkah 4: Anggap setiap lencongan sebagai permintaan keluar baharu

Matikan tindakan mengikut lencongan secara automatik. Bagi setiap respons dengan status lencongan, selesaikan Location terhadap URL semasa menggunakan penghurai yang sama, tingkatkan kiraan lompatan, dan mulakan semula pemeriksaan skema, port, maklumat pengguna (userinfo), DNS, alamat, dan sambungan. Tolak lokasi yang tiada atau tidak terbentuk dengan betul, gelung (loops), lencongan keempat, dan sebarang lompatan yang diselesaikan kepada alamat yang tidak dibenarkan.

Jangan majukan kuki pemanggil, pengepala kebenaran, atau pengepala sebarangan kepada hos pertama. Jangan majukan kelayakan yang ditetapkan oleh respons kepada asal yang berbeza. Pengambil menggunakan User-Agent tetap dan set pengepala tetap yang kecil. Memandangkan produk hanya memerlukan tajuk, GET adalah mencukupi; lencongan tidak boleh mengubah operasi menjadi POST yang dikawal oleh pemanggil dengan jasad permintaan.

Ini menutup kaedah pintasan biasa: URL awam yang dikawal oleh penyerang mengembalikan lencongan ke http://169.254.169.254/, http://127.0.0.1/, atau perkhidmatan dalaman. Meluluskan URL pertama sahaja akan memberi kebenaran kepada destinasi akhir yang berbeza daripada destinasi yang sebenarnya dihubungi.

Langkah 5: Jadikan rangkaian menolak apa yang terlepas oleh kod aplikasi

Jalankan pekerja pengambilan dalam segmen atau ruang nama (namespace) rangkaian khusus. Tembok api egressnya membenarkan DNS hanya kepada penyelesai terkawal dan HTTP/HTTPS hanya melalui proksi peka-dasar atau laluan awam yang diluluskan. Ia menafikan pelepasan gelung balik, julat perkhidmatan dalaman, rangkaian kluster, rangkaian korporat, ruang pautan-tempatan, dan titik akhir metadata awan untuk kedua-dua keluarga IP. Sahkan laluan efektif, bukan hanya peraturan bertulis.

Identiti perkhidmatan pekerja hanya mempunyai kebenaran yang diperlukan untuk membaca dan menyelesaikan kerja pratonton. Elakkan daripada meletakkan kelayakan awan yang luas dalam persekitarannya. Pada EC2, menyahdayakan metadata tika apabila tidak digunakan atau mewajibkan IMDSv2 mengurangkan pendedahan; AWS mendokumenkan kedua-dua titik akhir metadata IPv4 169.254.169.254 dan titik akhir IPv6 pilihan. Kawalan ini menambah pertahanan secara mendalam dan tidak menjadikan dasar URL sebagai pilihan.

Gunakan kolam pekerja yang berasingan daripada webhook dalaman atau klien pentadbiran. Pembantu HTTP generik yang boleh mencapai perkhidmatan peribadi tidak sepatutnya memproses URL yang tidak dipercayai. Percubaan yang dinafikan rangkaian, termasuk destinasi metadata, harus menghasilkan metrik dan amaran tanpa mendedahkan topologi dalaman kepada pemanggil.

Langkah 6: Hadkan pengambilan dan hurai hanya artifak yang dijanjikan

Gunakan batas masa berasingan untuk DNS, sambungan, bait pertama, bacaan melahu, dan batas masa keseluruhan tiga saat. Strimkan respons dan berhenti selepas 2 MiB kandungan yang dinyahmampat; had jasad termampat sahaja membenarkan bom penyahmampatan (decompression bomb). Terima hanya jenis kandungan yang diperlukan untuk tajuk HTML. Hadkan keserentakan setiap akaun dan secara global supaya pelayan awam yang perlahan tidak menggunakan semua pekerja.

Jangan cuba semula secara automatik. Percubaan semula mewujudkan satu lagi kebenaran keluar dan boleh menggandakan beban. Jika keperluan produk kemudiannya menambah percubaan semula, setiap percubaan bermula daripada penghuraian dan resolusi serta kekal di dalam belanjawan keseluruhan kerja tersebut.

Penghurai menganggap jasad sebagai berniat jahat. Ia tidak melaksanakan JavaScript, menyelesaikan entiti luaran XML, memuatkan imej, lembaran gaya, fon, iframe, atau skrip, atau mengikut arahan penyegaran metadata. Ekstrak tajuk dengan penghurai penstriman terhad atau terasing, normalkannya sebagai teks, hadkan panjangnya, dan kembalikan nilai itu sahaja. Jauhkan HTML mentah daripada respons API dan lepaskan (escape) tajuk tersebut pada sink rendering akhir.

Langkah 7: Cerap keputusan dan uji invarian peringkat soket

Catatkan hasil kerja, hos ternormal atau kunci hos yang memelihara privasi, skema, port efektif, kelas alamat yang dipilih, kiraan lencongan, bait, tempoh, dan kod sebab penafian yang stabil. Jangan log URL penuh, rentetan pertanyaan, maklumat pengguna, jasad respons, atau muatan DNS kerana URL boleh mengandungi rahsia. Jejaki kadar penafian untuk peraturan peribadi, pautan-tempatan, metadata, skema, port, lencongan, saiz, tamat masa, dan jenis kandungan.

Uji melalui penyelesai, proksi, tembok api, dan klien HTTP yang sebenar. Sertakan:

• varian gelung balik seperti 127.1, IPv6 ::1, dan IPv6 yang dipetakan IPv4;
• alamat peribadi, dikongsi, pautan-tempatan, multisiar, dikhaskan, dokumentasi, dan metadata;
• domain dengan satu jawapan awam dan satu jawapan peribadi, serta kedua-dua rekod A dan AAAA;
• penyelesai yang mengembalikan awam semasa pengesahan dan peribadi pada carian seterusnya;
• titik akhir awam yang melencong ke setiap keluarga alamat yang dinafikan dan titik akhir yang bergelung sebanyak empat kali;
• kelayakan terbenam, hos terenkod, skema bukan HTTP, port terlarang, dan URL tidak sah;
• pengepala perlahan, jasad terhenti, jasad ternyahmampat bersaiz lampau, dan bom mampatan;
• halaman HTML yang skrip atau imejnya menghala ke hos dalaman;
• halaman HTTPS awam yang sah dengan soketnya dipin manakala TLS mengesahkan nama hos asal;
• pintasan dasar aplikasi yang disengajakan yang masih disekat oleh tembok api egress.

Ujian pengikatan semula DNS mesti gagal jika klien melakukan carian kedua. Ujian TLS positif mesti gagal jika pengesahan sijil menyasarkan IP numerik secara tidak sengaja. Bersama-sama, ujian ini membuktikan bahawa pengesahan dan sambungan menggunakan identiti yang dimaksudkan.

Contoh Jawapan Berkualiti Tinggi

“Saya akan memodelkan pencegahan SSRF sebagai kebenaran keluar yang dilakukan oleh komponen yang membuka soket. API mengesahkan dan mengehadkan kadar pemanggil, menyimpan URL sebagai input yang tidak dipercayai, dan mengatur giliran kerja. Pekerja pengambilan menghuraikannya dengan penghurai berasaskan piawaian, menolak maklumat pengguna, skema bukan HTTP, dan port di luar 80 dan 443, serta mengambil hos dan laluan kanonikal hanya daripada penghurai tersebut.

Untuk literal IP, saya mengkanonikalkannya, menyahbungkus IPv6 yang dipetakan IPv4, dan menggunakan pengelas alamat awam yang diselenggara. Untuk nama hos, saya menyelesaikan semua jawapan A dan AAAA melalui penyelesai terkawal dan menolak keseluruhan destinasi jika mana-mana hasil adalah peribadi, gelung balik, dikongsi, pautan-tempatan, multisiar, dikhaskan, dokumentasi, metadata, atau sebaliknya di luar dasar. Saya kemudian menyambung terus ke satu IP yang diluluskan sambil mengekalkan nama hos asal untuk Host, TLS SNI, dan pengesahan sijil. Ini menghapuskan tetingkap carian-DNS-kedua yang digunakan oleh serangan pengikatan semula.

Lencongan dan percubaan semula automatik dinyahdayakan. Untuk sehingga tiga lencongan, saya menghurai lokasi baharu dan mengulangi kebenaran lengkap sebelum membuka soket lain. Saya hanya menghantar GET dengan pengepala tetap dan tiada kuki atau kelayakan pemanggil. Proksi egress khusus atau tembok api menafikan secara berasingan setiap laluan dalaman, kluster, korporat, pautan-tempatan, dan metadata melalui IPv4 dan IPv6. Pekerja mempunyai identiti perkhidmatan yang minimum dan tidak boleh menggunakan klien HTTP dalaman umum.

Setiap kerja mempunyai batas masa keseluruhan tiga saat dan had jasad ternyahmampat 2 MiB. Penghurai tidak melaksanakan sebarang skrip dan tidak memuatkan sub-sumber; ia hanya mengembalikan tajuk yang terhad panjangnya dan disanitasi. Saya melog kod sebab, kelas alamat, kiraan lencongan, bait, dan kependaman tanpa URL penuh. Sut penerimaan saya merangkumi jawapan DNS bercampur, pengikatan semula antara pemeriksaan dan sambungan, IPv6 dipetakan IPv4, lencongan-ke-metadata, bom gzip, jasad perlahan, TLS dengan soket dipin, dan pintasan dasar yang masih mesti dihentikan oleh rangkaian.”

Kesilapan Biasa

• Menyekat hanya localhost dan RFC 1918 → bentuk IPv4 alternatif, IPv6, pautan-tempatan, dikongsi, dikhaskan,

dan alamat metadata kekal boleh dicapai → **kanonikalkan dan kelaskan kedua-dua keluarga alamat dengan dasar destinasi awam yang diselenggara.**

• Mengesahkan dengan regex → pengesah dan penghurai HTTP boleh bercanggah mengenai kelayakan, pengekodan,

hos, dan port → gunakan satu penghurai berasaskan piawaian dan gunakan hanya medan kanonikalnya.

• Selesaikan, periksa, kemudian biarkan klien menyelesaikan semula → pengikatan semula DNS mengubah destinasi soket

selepas kelulusan → pin sambungan ke IP yang diperiksa sambil mengesahkan TLS terhadap nama hos.

• Luluskan hanya URL pertama → hos awam yang dibenarkan boleh melencong ke perkhidmatan dalaman →

nyahdayakan lencongan automatik dan beri kebenaran semula kepada setiap lompatan.

• Pilih jawapan selamat daripada hasil DNS bercampur → perubahan pemilihan alamat kemudiannya boleh mencapai

jawapan yang tidak selamat → tolak nama hos apabila mana-mana alamat yang dikembalikan melanggar dasar gesaan ini.

• Memajukan pengepala pemanggil → kuki atau nilai kebenaran bocor kepada hos pilihan penyerang →

bina permintaan keluar tetap tanpa kelayakan sekitaran.

• Bergantung pada IMDSv2 atau tetapan awan sahaja → perkhidmatan dalaman dan julat alamat lain kekal

terdedah → **gabungkan kebenaran aplikasi, identiti minimum, pengukuhan metadata, dan penafian egress.**

• Mengehadkan bait termampat sahaja → jasad kecil boleh mengembang sehingga memori atau CPU habis → **hadkan

bait ternyahmampat, kerja penghuraian, masa, dan keserentakan.**

• Menghurai halaman seperti pelayar → skrip dan sub-sumber mewujudkan permintaan keluar baharu yang tidak disemak

→ ekstrak hanya artifak yang dijanjikan dengan kandungan aktif dan resolusi entiti luaran dinyahdayakan.

• Melog URL penuh untuk penyahpepijatan → rahsia pertanyaan dan kelayakan berpindah ke sistem kebolehcerapan →

log medan kanonikal yang terhad dan kod sebab yang stabil.

Soalan Susulan

Apakah yang berubah apabila setiap destinasi merupakan rakan kongsi yang diketahui?

Gunakan senarai putih tepat bagi skema, nama hos, dan port yang dinormalkan dan sediakannya melalui konfigurasi yang disemak. Tetap selesaikan dan kelaskan alamat tersebut: rekod DNS yang terjejas atau kesilapan konfigurasi tidak seharusnya mengubah nama yang dipercayai menjadi laluan dalaman. Titik akhir rakan kongsi peribadi sepatutnya berada dalam penyepaduan berasingan yang disahkan dengan laluan rangkaian eksplisit, bukan dalam pekerja pratonton awam.

Bolehkah perkhidmatan menyokong lencongan merentasi domain dengan selamat?

Boleh, jika lencongan rentas domain merupakan keperluan produk dan setiap lompatan mengulangi keseluruhan dasar. Gugurkan kelayakan dan keadaan khusus asal, selesaikan nama hos baharu, kelaskan setiap hasil, pin sambungan baharu, dan kira lompatan tersebut. Dasar yang lebih mudah boleh mewajibkan asal yang sama, tetapi ia menolak pengarah lencongan awam biasa; penemu duga harus mendengar kompromi produk tersebut secara eksplisit.

Mengapakah menolak nama hos apabila satu jawapan DNS adalah awam dan satu lagi adalah peribadi?

Ia mewujudkan kontrak gagal-tutup (fail-closed) yang stabil. Susunan alamat berbeza-beza merentasi penyelesai, keluarga IP, dan percubaan semula. Memilih satu jawapan awam semasa pengesahan manakala komponen lain kemudiannya memilih jawapan peribadi akan membuka semula jurang keselamatan. Produk yang mahukan penerimaan separa memerlukan komponen yang sama untuk memin hanya alamat yang diluluskan bagi setiap sambungan dan mesti menguji failover dengan teliti; gesaan ini mengambil dasar konservatif yang lebih mudah.

Bagaimana jika produk memerlukan tangkapan skrin atau pratonton yang dirender oleh JavaScript?

Letakkan rendering dalam peringkat yang lebih terasing dengan dasar egress yang sama. Pelayar mewujudkan banyak permintaan sekunder, jadi pintas dan beri kebenaran kepada setiap navigasi, lencongan, pekerja (worker), WebSocket, dan sub-sumber. Nyahdayakan akses fail tempatan dan ciri pelayar yang tidak diperlukan, hadkan CPU, memori, masa, dan muat turun, serta musnahkan kotak pasir (sandbox) selepas setiap kerja. Tindakan rendering tidak mewarisi kepercayaan daripada URL halaman awal.

Bagaimanakah anda membuktikan tembok api berkesan selepas penggunaan?

Jalankan kenari (canary) terkawal daripada identiti dan ruang nama pekerja sebenar terhadap destinasi IPv4, IPv6, kluster, korporat, dan metadata yang dinafikan, kemudian sahkan kedua-dua kegagalan sambungan dan telemetri rangkaian yang dijangkakan. Ulangi selepas perubahan laluan, kontena, proksi, atau rangkaian awan. Semakan konfigurasi menunjukkan niat; kenari dan log aliran menunjukkan laluan yang efektif.