Apa itu SSRF? Membatasi permintaan keluar dari server

Apa itu SSRF?

Server-side request forgery (SSRF) terjadi ketika masukan membuat server mengakses tujuan yang seharusnya tidak dapat dipilih pengguna. Contohnya berkaitan dengan impor gambar dari URL, pembuatan pratinjau tautan, dan pengiriman callback.

Server mungkin dapat menjangkau layanan yang tidak terbuka dari internet. Karena itu, memindahkan pengambilan URL dari browser ke server belum membuat fitur aman. Perlu pembatasan terhadap koneksi yang dilakukan server itu sendiri.

Contoh: mengambil gambar katalog

Dalam contoh fiktif, toko ingin mengambil foto produk dari mitra yang telah disetujui. Kebutuhan bisnisnya terbatas: hanya mengambil gambar dari daftar mitra tertentu.

Tim memilih menyimpan identitas mitra dan membentuk tujuan di server, alih-alih menerima sembarang URL lengkap. Akun proses pengambil gambar juga tidak mendapat akses bebas ke seluruh jaringan internal. Jika tujuan tidak sesuai aturan, pekerjaan dihentikan sebelum mengambil data.

Bedakan dua jenis kebutuhan

Kebutuhan	Pertanyaan desain
Hanya menghubungi mitra yang diketahui	Dapatkah tujuan berasal dari daftar tetap dan komponen permintaan dibentuk aplikasi?
Mengambil sumber publik yang beragam	Bagaimana aplikasi menolak tujuan internal/nonpublik dan membatasi koneksi keluar secara berlapis?

Daftar domain saja belum cukup bila hasil DNS, redirect, atau parser URL membuat koneksi berakhir di tempat lain. Gunakan parser yang sesuai, tangani IPv4 serta IPv6, dan periksa tujuan aktual saat koneksi dibentuk. Tolak bentuk yang ambigu atau tidak didukung.

Batas yang perlu disepakati

• Protokol, tujuan, port, dan fungsi yang memang diperlukan fitur.
• Kebijakan redirect: matikan jika tidak diperlukan; jika diperlukan, periksa tujuan setiap lompatan.
• Pembatasan jaringan keluar agar proses hanya menjangkau layanan yang dibutuhkan.
• Batas waktu, ukuran respons, dan jumlah pekerjaan agar fitur tidak menghabiskan kapasitas.
• Perilaku saat DNS atau pemeriksaan tujuan gagal: jangan melanjutkan dengan izin lebih longgar.

Untuk fitur yang hanya mengambil sumber publik, masukkan loopback, alamat privat, link-local, serta layanan metadata/internal ke dalam analisis tujuan terlarang. Daftar dan penegakannya perlu mengikuti lingkungan; jangan menyalin daftar alamat singkat lalu menganggapnya lengkap.

Verifikasi tanpa menjangkau sistem pihak lain

Siapkan tujuan uji yang dikelola tim: satu tujuan sah, satu yang harus ditolak, dan satu yang melakukan redirect. Catat tujuan akhir dan keputusan kebijakan. Bukti yang dicari adalah tidak terjadinya koneksi terlarang, bukan sekadar pesan gagal pada antarmuka.

Hubungkan pemeriksaan dengan keamanan cloud dan pengiriman webhook. Panduan ini membahas pencegahan; perubahan aturan jaringan tetap perlu diuji terhadap layanan sah.