Pengantar

Keamanan aplikasi web tidak hanya bergantung pada perlindungan terhadap pengguna, tetapi juga pada bagaimana server menangani permintaan (request) yang diterimanya. Salah satu kerentanan yang sering luput dari perhatian adalah Server-Side Request Forgery (SSRF). Meskipun tidak selalu menghasilkan dampak langsung yang terlihat, SSRF dapat menjadi pintu masuk bagi penyerang untuk mengakses layanan internal, mencuri data sensitif, hingga mengambil alih infrastruktur cloud.

Kerentanan ini semakin relevan di era cloud computing dan arsitektur microservices, di mana aplikasi sering berkomunikasi dengan berbagai layanan internal maupun eksternal. Jika mekanisme validasi permintaan tidak diterapkan dengan benar, penyerang dapat memanfaatkan server sebagai perantara untuk mengirimkan permintaan ke tujuan yang seharusnya tidak dapat diakses secara langsung.

Karena dampaknya yang serius, SSRF masuk dalam daftar kerentanan penting yang perlu diwaspadai oleh pengembang maupun tim keamanan aplikasi.

Apa Itu Server-Side Request Forgery (SSRF)?

Server-Side Request Forgery (SSRF) adalah jenis kerentanan keamanan yang memungkinkan penyerang memaksa server mengirimkan permintaan (request) ke alamat atau layanan yang dipilih oleh penyerang.

Alih-alih berkomunikasi dengan server tujuan yang sah, aplikasi justru mengirimkan permintaan ke alamat lain, termasuk:

  • Server internal.
  • Database internal.
  • Metadata cloud.
  • API internal.
  • Perangkat jaringan.

Menurut OWASP, SSRF terjadi ketika aplikasi mengambil sumber daya dari URL yang diberikan pengguna tanpa melakukan validasi yang memadai (dikutip dari https://owasp.org/www-community/attacks/Server_Side_Request_Forgery).

Bagaimana SSRF Terjadi?

Banyak aplikasi menyediakan fitur yang memungkinkan server mengambil data dari sebuah URL, misalnya:

  • Mengambil gambar dari alamat tertentu.
  • Mengunduh dokumen.
  • Memeriksa status sebuah website.
  • Mengambil data dari API eksternal.

Masalah muncul ketika aplikasi menerima URL dari pengguna tanpa melakukan validasi.

Sebagai contoh:

  1. Pengguna memasukkan URL ke dalam aplikasi.
  2. Server menerima URL tersebut.
  3. Server mengirimkan permintaan ke alamat yang diberikan.
  4. Penyerang mengganti URL tujuan menjadi alamat internal.
  5. Server tanpa sadar mengakses sistem yang seharusnya tidak dapat dijangkau dari internet.

Karena permintaan berasal dari server yang dipercaya, firewall atau sistem keamanan sering kali mengizinkan akses tersebut.

baca juga : Green Computing: Strategi Membangun Teknologi yang Lebih Ramah Lingkungan

Mengapa SSRF Berbahaya?

Mengakses Jaringan Internal

SSRF memungkinkan penyerang mengakses layanan yang hanya tersedia di jaringan internal.

Misalnya:

  • Dashboard administrasi.
  • Database.
  • API internal.
  • Server monitoring.

Mengambil Metadata Cloud

Pada lingkungan cloud, SSRF sering dimanfaatkan untuk mengakses Instance Metadata Service (IMDS).

Metadata ini dapat berisi:

  • Access token.
  • Kredensial sementara.
  • Informasi konfigurasi.
  • Identitas instance cloud.

Apabila berhasil diperoleh, data tersebut dapat digunakan untuk mengakses layanan cloud lainnya.

Melakukan Port Scanning

Server dapat digunakan untuk memindai port yang terbuka pada jaringan internal sehingga penyerang memperoleh gambaran mengenai infrastruktur target.

Menjadi Tahap Awal Serangan Lanjutan

SSRF sering digunakan sebagai langkah awal sebelum melakukan eksploitasi yang lebih serius, seperti pengambilalihan akun cloud atau pergerakan lateral (lateral movement) di dalam jaringan.

Contoh Skenario SSRF

Bayangkan sebuah aplikasi menyediakan fitur untuk mengambil gambar dari URL berikut:

https://example.com/image.jpg

Aplikasi kemudian mengunduh gambar tersebut melalui server.

Namun, penyerang mengganti alamat tersebut menjadi:

http://127.0.0.1/admin

atau

http://169.254.169.254/

Jika aplikasi tidak melakukan validasi, server akan mengakses alamat tersebut dan mengembalikan hasilnya kepada penyerang.

Pada lingkungan cloud, alamat metadata seperti 169.254.169.254 sering menjadi target karena dapat berisi informasi sensitif mengenai instance yang sedang berjalan.

Jenis-Jenis SSRF

Basic SSRF

Server mengakses alamat yang diberikan pengguna tanpa pembatasan.

baca juga : Network Observability vs Monitoring: Mana yang Lebih Efektif untuk Infrastruktur Modern?

Blind SSRF

Server tetap mengirimkan permintaan, tetapi hasilnya tidak ditampilkan kepada penyerang.

Walaupun demikian, penyerang masih dapat mengetahui apakah permintaan berhasil melalui efek samping tertentu, seperti perubahan log atau interaksi dengan server eksternal.

Second-Order SSRF

Permintaan berbahaya tidak langsung dijalankan saat input diterima, melainkan diproses pada waktu lain oleh sistem.

Jenis ini lebih sulit dideteksi karena eksploitasi terjadi secara tidak langsung.

Cara Mencegah SSRF

Validasi URL

Pastikan aplikasi hanya menerima URL dari domain yang telah dipercaya (allowlist).

Pendekatan ini lebih aman dibandingkan hanya memblokir beberapa domain tertentu.

Batasi Akses Jaringan

Server aplikasi sebaiknya tidak memiliki akses bebas ke seluruh jaringan internal.

Gunakan firewall dan aturan jaringan untuk membatasi komunikasi yang tidak diperlukan.

Nonaktifkan Akses ke Metadata Cloud

Pada lingkungan cloud, gunakan mekanisme perlindungan seperti IMDSv2 atau pembatasan akses metadata agar informasi sensitif tidak dapat diakses sembarangan.

Validasi DNS dan IP

Pastikan URL tidak mengarah ke:

  • localhost
  • 127.0.0.1
  • ::1
  • Rentang IP privat.
  • Alamat metadata cloud.

Monitoring dan Logging

Pantau permintaan keluar (outbound request) dari server.

Permintaan menuju alamat internal yang tidak biasa dapat menjadi indikator adanya percobaan eksploitasi SSRF.

SSRF di Era Cloud Computing

Migrasi ke cloud membuat SSRF menjadi semakin berbahaya.

Banyak layanan cloud menyediakan metadata yang dapat diakses dari dalam instance untuk mempermudah autentikasi layanan.

Apabila metadata tersebut berhasil diakses melalui SSRF, penyerang berpotensi memperoleh kredensial sementara yang memiliki hak akses ke berbagai layanan cloud.

Karena alasan inilah, SSRF menjadi salah satu ancaman utama pada aplikasi cloud-native.

Praktik Terbaik Mengurangi Risiko SSRF

Beberapa langkah yang dapat diterapkan organisasi antara lain:

  • Menggunakan daftar domain yang diizinkan (allowlist).
  • Memisahkan jaringan aplikasi dan layanan internal.
  • Membatasi akses server ke internet maupun jaringan internal sesuai kebutuhan.
  • Memperbarui framework dan library secara berkala.
  • Melakukan pengujian keamanan aplikasi sebelum dipublikasikan.
  • Memanfaatkan Web Application Firewall (WAF) sebagai lapisan perlindungan tambahan.

Pendekatan berlapis seperti ini dapat mengurangi peluang eksploitasi meskipun terdapat kesalahan konfigurasi pada aplikasi.

baca juga : Neuromorphic Computing: Komputasi yang Meniru Cara Kerja Otak Manusia

Kesimpulan

Server-Side Request Forgery (SSRF) merupakan kerentanan yang memungkinkan penyerang memanfaatkan server untuk mengirimkan permintaan ke sistem lain yang seharusnya tidak dapat diakses secara langsung. Dampaknya dapat mencakup akses ke jaringan internal, pencurian metadata cloud, pemindaian layanan internal, hingga menjadi pintu masuk bagi serangan yang lebih kompleks.

Di era cloud computing dan arsitektur microservices, risiko SSRF semakin meningkat karena banyak aplikasi bergantung pada komunikasi antarlayanan. Oleh karena itu, penerapan validasi URL, pembatasan akses jaringan, perlindungan metadata cloud, serta monitoring terhadap permintaan keluar menjadi langkah penting untuk meminimalkan risiko eksploitasi.

Menurut OWASP Web Security Testing Guide, pengujian terhadap kerentanan SSRF sebaiknya menjadi bagian dari proses keamanan aplikasi karena dampaknya dapat meluas hingga ke infrastruktur internal (dikutip dari https://owasp.org/www-project-web-security-testing-guide/).

Related Posts: