Menguji SSRF terhadap Batas Akses Metadata Cloud
SSRF mengubah posisi jaringan server menjadi kemampuan membuat request yang dikendalikan penyerang. Endpoint metadata cloud membuat dampaknya besar bila credential workload dapat dijangkau. CWE-918 menjelaskan server-side request forgery; AWS mendokumentasikan penggunaan token IMDSv2.
Uji asumsi jaringan
Uji fitur URL memakai loopback, private range, alamat link-local, redirect, notasi IP alternatif, serta perubahan DNS setelah validasi. Contoh: importer gambar mengikuti redirect dari host publik ke alamat metadata. Contoh lain: previewer PDF meresolusikan hostname ke layanan privat setelah pemeriksaan allowlist awal.
Checklist batas metadata
| Batas | Verifikasi | Sinyal gagal |
|---|---|---|
| egress | tolak metadata dan private range | koneksi diblokir |
| metadata | IMDSv2 diwajibkan | request v1 gagal |
| role workload | izin minimum | credential tidak dapat membuat daftar data lain |
| fetcher | tidak mengikuti redirect otomatis | redirect tercatat lalu ditolak |
Aturan keputusan: workload pengambil URL tidak boleh menjangkau layanan metadata kecuali jalur itu memang diperlukan dan diotorisasi terpisah.
Remediasi
Gunakan kebijakan proxy keluar, IMDSv2, credential workload berumur pendek, dan validasi tujuan setelah setiap redirect serta resolusi. Pengujian perlu otorisasi tertulis karena menyentuh batas internal. Pengujian aplikasi web dapat memvalidasi jalur yang disetujui.
Buktikan batas pada deployment
Uji perilaku aplikasi dan perilaku jaringan secara terpisah. Validasi harus menilai setiap alamat hasil resolusi, termasuk IPv6, dan penanganan redirect harus mengulang pemeriksaan tujuan sebelum koneksi. Jangan mengandalkan hostname yang tampak publik. Kebijakan egress perlu menolak metadata dan tujuan privat walau jalur kode baru kelak melewatkan validasi. AWS mendokumentasikan bahwa IMDSv2 memakai token dari PUT dan dapat diwajibkan sehingga panggilan IMDSv1 tanpa token menerima unauthorized.
Simpan uji yang disetujui terhadap metadata terblokir, loopback, alamat privat, alamat link-local, dan redirect publik-ke-privat. Pastikan fetcher tidak dapat memakai proxy environment atau credential turunan untuk melewati kebijakan. Batasi izin role workload agar request rusak tidak dapat membuat daftar resource lain. Owner: pemilik platform. Lulus: tiap tujuan terlarang diblokir dan tidak ada respons credential. Gagal: jalur fetcher mencapai metadata atau layanan internal. Pengecualian memerlukan tujuan, alasan bisnis, aturan egress, kontrol kompensasi, persetujuan risiko, owner perbaikan, dan tanggal kedaluwarsa.
Batas uji metadata
Jangan memakai credential produksi. Pada lingkungan disetujui, uji input fetcher yang menargetkan endpoint metadata cloud IPv4 dan IPv6. Hasil yang diharapkan: koneksi ditolak sebelum body respons dibaca. Periksa setting metadata secara terpisah dan buktikan akses tanpa token gagal ketika IMDSv2 diwajibkan. Simpan bukti kebijakan yang direduksi.
Bukti egress metadata
Output yang diharapkan: ID request fetch, tujuan terparse, setiap jawaban A dan AAAA, hop redirect, hasil firewall, opsi IMDS, role workload. Bukti ini menghubungkan blok egress dengan jejak jaringan yang tercatat.
Kegagalan teruji: URL gambar publik melakukan redirect ke alamat link-local. Fetcher harus berhenti sebelum membaca header dan log egress harus menunjukkan tujuan yang ditolak.
Kasus tepi: Layanan dapat memerlukan metadata melalui jalur SDK yang disetujui. Jalur itu tidak boleh memberi fetcher yang dikendalikan pengguna rute jaringan sama.
Uji penutupan: Jalankan kasus redirect setelah refresh cache DNS. Penutupan lulus ketika telemetri aplikasi dan jaringan sepakat tidak ada respons metadata yang dikembalikan.
Latihan kontrol jaringan
Daftarkan setiap komponen yang dapat memulai trafik HTTP, DNS, konversi gambar, render dokumen, atau callback. Inventory sering menemukan worker yang tidak memakai fetch helper utama. Untuk tiap komponen, catat subnet, security group atau kebijakan firewall, rute proxy, dan identitas layanan. Uji penolakan harus mencakup literal desimal dan IPv6, bukan hanya hostname metadata yang dikenal. Uji juga harus membuktikan body respons redirect dibuang, bukan diproses sebagian sebelum review tujuan.
Ketika workload sah mengakses metadata instance, isolasikan jalur client itu dari input pengguna. Jalur tersebut hanya boleh meminta metadata terdokumentasi melalui SDK atau tujuan tetap dan tidak boleh mewarisi URL, header, method, atau konfigurasi proxy sembarang. Review izin role setelah hardening metadata: memblokir endpoint mengurangi paparan, sedangkan least privilege mengurangi dampak bila ada jalur credential lain. Simpan instruksi rollback darurat, tetapi wajibkan persetujuan platform tercatat sebelum melemahkan setting IMDS.
Pertahanan metadata memerlukan observabilitas saat fetch gagal. Kirim metrik terbatas atau kategori audit untuk kelas tujuan ditolak tanpa menyimpan nilai query URL. Bandingkan penolakan kebijakan dengan penolakan firewall; ketidaksesuaian menunjukkan satu lapisan terlewati atau salah konfigurasi. Uji jaringan container dan host secara terpisah karena hop limit serta jalur proxy dapat berbeda. Catatan penutupan harus menyebut image runtime dan revisi kebijakan jaringan yang dipakai.
Uji juga request yang membawa hostname publik tetapi memakai proxy environment yang mengarah ke jaringan internal. Hasil yang benar adalah konfigurasi proxy tidak dipakai oleh fetcher terbatas, atau proxy tersebut menerapkan aturan tujuan setara. Catat pilihan itu pada kontrak service agar perubahan deployment tidak membuka jalur baru.