SSRF, Celah yang Membuat Server Menyerang Dirinya Sendiri

SSRF (Server-Side Request Forgery) adalah celah yang membuat server mengirim permintaan ke alamat pilihan penyerang. Karena permintaan itu datang dari dalam, server bisa menjangkau tempat yang tidak bisa dijangkau penyerang secara langsung: layanan internal, panel admin yang hanya mendengarkan di localhost, database tanpa password di jaringan privat, sampai endpoint metadata cloud yang menyimpan kredensial.

Kenapa ini penting? Banyak aplikasi modern punya fitur yang "mengambil sesuatu dari URL": pratinjau tautan, impor gambar dari alamat web, webhook, pembuat PDF dari halaman, atau integrasi API. Setiap fitur seperti itu adalah pintu SSRF bila tujuannya tidak dibatasi.

Bagaimana SSRF bekerja?

Bayangkan fitur "unggah foto profil dari URL". Pengguna mengisi alamat gambar, lalu server mengunduhnya. Normalnya isinya https://contoh.com/foto.jpg.

Penyerang mengisi alamat lain:

• http://127.0.0.1:8080/admin untuk membuka panel admin yang hanya bisa diakses dari server itu sendiri.
• http://10.0.0.5:6379/ untuk mencolek Redis di jaringan internal.
• http://169.254.169.254/ untuk mengakses layanan metadata instance di banyak penyedia cloud.

Server patuh saja, karena kodenya memang hanya menerima URL lalu mengambilnya. Kalau respons ditampilkan kembali ke pengguna, penyerang bisa membaca hasilnya. Ini disebut SSRF biasa. Kalau respons tidak ditampilkan, penyerang masih bisa menebak dari waktu respons atau pesan error. Ini disebut blind SSRF, lebih lambat dieksploitasi tapi tetap berbahaya.

Kenapa endpoint metadata cloud jadi sasaran favorit?

Di banyak platform cloud, mesin virtual bisa bertanya ke alamat khusus 169.254.169.254 untuk mengetahui informasi tentang dirinya. Pada konfigurasi tertentu, jawabannya termasuk kredensial sementara untuk peran (role) yang terpasang di mesin itu.

Artinya, satu celah SSRF di aplikasi web bisa berujung pada pencurian kunci akses cloud. Dengan kunci itu, penyerang bisa membaca bucket penyimpanan atau layanan lain sesuai izin role tersebut.

Penyedia cloud sudah menambah perlindungan. Di AWS misalnya, IMDSv2 mewajibkan permintaan token lewat metode PUT dengan header khusus sebelum metadata bisa dibaca, sehingga permintaan GET sederhana hasil SSRF tidak cukup. AWS menganjurkan mewajibkan IMDSv2 pada instance. Kalau kamu memakai cloud, periksa apakah pengaturan serupa sudah aktif.

Di mana SSRF dalam daftar OWASP?

Pada OWASP Top 10 2021, SSRF punya kategori sendiri (A10). Pada OWASP Top 10 2025, SSRF (CWE-918) digabung ke dalam kategori A01 Broken Access Control. Penggabungan ini tidak berarti risikonya mengecil. Intinya tetap sama: server diberi akses ke sumber daya yang seharusnya tidak boleh dijangkau atas permintaan pengguna.

Kalau ingin gambaran utuh seluruh kategori, baca OWASP Top 10 untuk pemilik website. Celah lain di kategori yang sama, yaitu IDOR, juga sering ditemukan di aplikasi bisnis.

Fitur aplikasi yang rawan SSRF

Bagaimana cara mencegah SSRF?

Pencegahan yang efektif berlapis, karena satu lapis saja mudah diakali.

• Pakai daftar izin (allowlist), bukan daftar larangan. Kalau fitur hanya perlu mengambil dari domain mitra tertentu, izinkan domain itu saja. Daftar larangan seperti "tolak 127.0.0.1" gampang dilewati dengan penulisan alamat lain, misalnya bentuk desimal, IPv6, atau nama domain yang mengarah ke IP lokal.
• Validasi setelah resolusi DNS. Cek alamat IP hasil resolusi, bukan hanya teks URL. Tolak rentang privat, loopback, link-local (169.254.0.0/16), dan alamat khusus lainnya. Pastikan koneksi benar-benar dibuat ke IP yang sudah divalidasi, agar tidak tertipu DNS rebinding.
• Matikan pengalihan otomatis (redirect) di klien HTTP, atau validasi ulang setiap tujuan pengalihan.
• Batasi skema. Izinkan hanya https (atau http bila perlu). Tolak file://, gopher://, ftp://, dan skema lain yang tidak dibutuhkan.
• Jangan kembalikan respons mentah ke pengguna. Ambil data yang diperlukan saja, misalnya pastikan hasilnya memang gambar.
• Batasi jaringan keluar di level server. Aturan firewall yang mencegah server aplikasi menghubungi jaringan internal atau endpoint metadata adalah lapisan terakhir yang sangat membantu.

Apakah WAF cukup untuk menahan SSRF?

WAF bisa menghentikan pola serangan yang umum, misalnya parameter berisi 169.254.169.254 atau localhost. Tapi WAF melihat permintaan dari luar, bukan logika aplikasimu. Penyerang yang memakai pengodean alamat yang tidak lazim atau domain miliknya sendiri yang mengarah ke IP internal masih bisa lolos.

Jadi WAF berguna sebagai lapisan tambahan, sementara perbaikan utama tetap di kode dan konfigurasi jaringan. Penjelasan tentang kapan WAF layak dipakai bisa jadi bahan pertimbangan.

Cara menguji apakah aplikasimu rawan

Kumpulkan dulu semua fitur yang menerima URL atau alamat dari pengguna, termasuk yang tersembunyi di API. Untuk setiap fitur, coba masukkan alamat ke server uji yang kamu kendalikan dan lihat apakah server aplikasi menghubunginya. Jika ya, lanjutkan dengan mencoba alamat lokal di lingkungan uji, bukan di produksi.

Pengujian seperti ini sebaiknya dilakukan oleh orang yang paham dan dengan izin tertulis bila aplikasinya milik pihak lain. Hasilnya dicatat sebagai temuan, lalu diperbaiki di kode.