Keamanan aplikasi web saat ini bukan lagi sekadar soal password yang kuat atau penggunaan HTTPS. Di balik layar, ada banyak proses kompleks yang melibatkan komunikasi antar server, API pihak ketiga, hingga layanan cloud internal. Semua proses ini berjalan otomatis, cepat, dan sering kali tidak terlihat oleh pengguna. Namun, justru di titik inilah banyak celah keamanan muncul tanpa disadari oleh developer.
Salah satu celah yang sering diremehkan tapi dampaknya sangat besar adalah Server Side Request Forgery (SSRF). SSRF memanfaatkan kepercayaan server terhadap request internal, membuat penyerang bisa “menyuruh” server melakukan request berbahaya. Jika tidak dipahami dengan baik, SSRF bisa menjadi pintu masuk untuk kebocoran data, akses internal service, bahkan pengambilalihan sistem.
Apa Itu Server Side Request Forgery (SSRF)?
Server Side Request Forgery atau SSRF adalah celah keamanan di mana penyerang mampu memanipulasi aplikasi agar server melakukan request ke lokasi yang tidak seharusnya. Biasanya, request ini diarahkan ke internal network, localhost, atau layanan sensitif yang tidak bisa diakses langsung dari luar.
Secara sederhana, SSRF terjadi ketika aplikasi menerima input berupa URL atau alamat resource, lalu server memprosesnya tanpa validasi ketat. Server bertindak seperti “kurir polos” yang mengirim permintaan ke mana pun tanpa curiga. Karena request berasal dari server itu sendiri, sistem internal menganggapnya aman.
Masalahnya, server biasanya memiliki hak akses yang jauh lebih tinggi dibanding user biasa. Ketika SSRF berhasil dieksploitasi, penyerang tidak lagi bertindak sebagai user eksternal, melainkan seolah-olah menjadi bagian dari sistem internal. Inilah yang membuat SSRF sangat berbahaya, terutama pada aplikasi modern berbasis cloud dan microservices.
Bagaimana Cara Kerja SSRF?
Cara kerja SSRF berawal dari fitur aplikasi yang membutuhkan request ke resource eksternal. Contohnya fitur fetch URL, upload gambar via link, preview website, webhook, atau integrasi API. Aplikasi menerima input URL dari user, lalu server melakukan request HTTP ke URL tersebut.
Masalah muncul ketika input ini tidak divalidasi dengan benar. Penyerang bisa mengganti URL eksternal dengan alamat internal seperti http://localhost, http://127.0.0.1, atau IP private seperti 192.168.x.x. Karena request dilakukan oleh server, firewall internal biasanya tidak memblokirnya.
Secara alur, SSRF bisa digambarkan seperti ini:
- User mengirim URL ke aplikasi
- Aplikasi meneruskan URL ke server
- Server melakukan request tanpa filter
- Request mencapai layanan internal
Server secara tidak sadar menjadi proxy untuk penyerang. Jika layanan internal merespons dengan data sensitif, data tersebut bisa dikirim kembali ke penyerang. Inilah alasan utama mengapa SSRF sering disebut sebagai vulnerability “diam-diam mematikan”.
Jenis-Jenis SSRF
SSRF tidak hanya satu bentuk. Ada beberapa jenis SSRF yang sering ditemukan dalam pengujian keamanan aplikasi.
- SSRF Klasik
Jenis ini memberikan response langsung ke penyerang. Jika server berhasil mengakses resource internal, hasilnya langsung terlihat di response aplikasi. Jenis ini paling mudah dikenali dan dieksploitasi. - Blind SSRF
Pada blind SSRF, penyerang tidak mendapatkan response langsung. Namun, request tetap dijalankan di server. Biasanya blind SSRF dideteksi melalui log, DNS interaction, atau delay response. - SSRF Berbasis URL Scheme
SSRF tidak selalu menggunakan HTTP. Beberapa aplikasi rentan terhadap skema lain sepertifile://,ftp://, ataugopher://. Ini membuka potensi membaca file lokal atau berinteraksi dengan service lain.
Memahami jenis SSRF sangat penting agar kamu tidak hanya fokus pada satu skenario serangan saja.
Contoh Kasus SSRF dalam Aplikasi Nyata
Salah satu contoh paling umum SSRF adalah pada fitur upload gambar via URL. Aplikasi meminta user memasukkan link gambar, lalu server mendownload gambar tersebut. Jika tidak ada validasi, URL bisa diarahkan ke internal service.
Contoh lain adalah webhook. Banyak aplikasi menerima endpoint webhook dari user atau pihak ketiga. Jika endpoint tersebut tidak dibatasi, penyerang bisa mengarahkan webhook ke internal API yang sensitif.
Kasus SSRF juga sering ditemukan di platform cloud besar. Banyak kebocoran credential cloud terjadi karena SSRF yang mengakses metadata service seperti 169.254.169.254. Dari sini, penyerang bisa mendapatkan token, role, dan akses ke resource cloud lainnya.
Dampak dan Risiko SSRF
Dampak SSRF jauh lebih serius dibanding yang terlihat di permukaan. SSRF bukan hanya soal request ilegal, tapi tentang eskalasi akses.
Risiko utama SSRF meliputi:
- Akses ke layanan internal yang seharusnya private
- Kebocoran data sensitif seperti credential dan token
- Port scanning internal untuk menemukan service lain
- Potensi Remote Code Execution (RCE) pada sistem tertentu
Pada arsitektur microservices, SSRF bisa menjadi jalan pintas untuk berpindah dari satu service ke service lain. Sekali berhasil, dampaknya bisa menjalar ke seluruh sistem.
Perbandingan SSRF dengan Vulnerability Serupa
Berikut merupakan perbandingan yang bisa membuat kamu lebih mengerti lagi menganai serangan ini dengan yang lain:
| Aspek | SSRF | CSRF | Open Redirect |
|---|---|---|---|
| Target utama | Server internal | User | User |
| Arah serangan | Server ke server | User ke aplikasi | Redirect eksternal |
| Dampak | Tinggi | Menengah | Rendah–menengah |
| Kompleksitas | Tinggi | Menengah | Rendah |
Cara Mencegah SSRF
Pencegahan SSRF harus dilakukan dari sisi kode dan infrastruktur. Beberapa langkah penting yang bisa diterapkan:
- Validasi dan sanitasi input URL
Pastikan hanya domain atau protokol tertentu yang diizinkan. - Gunakan whitelist, bukan blacklist
Blacklist mudah dilewati. Whitelist jauh lebih aman. - Batasi akses network internal
Server aplikasi seharusnya tidak bebas mengakses semua network. - Disable URL scheme berbahaya
Blokirfile://,gopher://, dan skema tidak diperlukan.
Pendekatan berlapis sangat penting karena satu lapisan saja sering tidak cukup.
Kesimpulan
Pada pembahasan kita di atas dapat kita simpulkan bahwa Server Side Request Forgery (SSRF) adalah vulnerability yang sering luput dari perhatian, tapi memiliki dampak yang sangat besar. Dengan memanfaatkan kepercayaan server terhadap request internal, SSRF bisa membuka pintu ke layanan yang seharusnya tertutup rapat.
Bagi programmer, mahasiswa IT, dan pelajar yang mendalami keamanan aplikasi, memahami SSRF bukan lagi pilihan, tapi kebutuhan. Dengan desain aplikasi yang aman, validasi input yang ketat, dan arsitektur network yang benar, SSRF bisa dicegah sebelum menjadi bencana.
Artikel ini merupakan bagian dari seri artikel belajar Cyber Security dan jika ada ide topik yang mau kami bahas silahkan komen di bawah ya..
