Dalam cyber security, Server Side Request Forgery (SSRF) jadi salah satu yang wajib mendapatkan perhatian serius. 

Pasalnya, SSRF jadi pintu masuk ke sistem internal server tanpa perlu membobol firewall secara langsung. 

Banyak kasus kebocoran data dan kompromi cloud infrastructure ternyata bermula dari satu request URL yang terlihat normal.

Masalahnya, SSRF bekerja dengan memanfaatkan server korban sebagai perantara. Jadi attacker tidak menyerang target secara langsung, melainkan menyuruh server melakukannya sendiri. 

Di lingkungan cloud dan microservices modern, celah seperti ini makin berbahaya karena satu server biasanya terhubung ke banyak layanan internal lain.

Apa Itu SSRF?

SSRF atau Server-Side Request Forgery merupakan celah keamanan yang memungkinkan attacker memanfaatkan server untuk mengirim request ke target lain. 

Target tersebut bisa berupa layanan internal, database, metadata cloud, sampai API privat yang seharusnya tertutup dari akses publik.

Kasus seperti ini sering muncul pada fitur input URL. Misalnya fitur upload gambar lewat link, webhook callback, import data eksternal, sampai preview website. 

Sistem akan mengambil data dari URL yang pengguna masukkan. Masalah mulai muncul ketika server terlalu percaya pada input tersebut.

Attacker lalu menyisipkan URL berbahaya seperti:

http://localhost:8080

http://169.254.169.254

file:///etc/passwd

Server akhirnya mengakses resource internal miliknya sendiri. Padahal resource tersebut sebelumnya aman karena berada dalam jaringan privat atau terlindungi firewall.

SSRF terasa makin berbahaya karena infrastruktur modern saling terhubung. Banyak aplikasi sekarang memakai container, Kubernetes, microservices, Redis, internal API, sampai layanan cloud metadata. 

Ketika satu celah SSRF terbuka, attacker bisa bergerak ke sistem lain dengan lebih mudah.

Karena itu, OWASP memasukkan SSRF ke daftar Top 10 vulnerability modern. Dampaknya memang serius, apalagi pada sistem cloud dan backend berskala besar.

Dampak Nyata dari SSRF

SSRF bisa memberikan berbagai dampak nyata bagi server yang terkena, seperti: 

1. Kebocoran Data Internal Server

Dampak paling umum dari SSRF adalah kebocoran data internal. Attacker memanfaatkan server untuk membaca resource yang sebelumnya tersembunyi dari internet publik.

Targetnya cukup beragam. Mulai dari file konfigurasi aplikasi, token autentikasi, environment variable, sampai kredensial database. 

Kalau server memakai layanan cloud seperti AWS EC2 metadata service, attacker bahkan bisa mencuri access key cloud.

Masalahnya, metadata cloud sering menyimpan kredensial penting untuk akses layanan lain. 

Setelah attacker memperoleh token tersebut, akses mereka bisa meluas ke storage, database, atau instance cloud lain.

Kasus Capital One tahun 2019 sering jadi contoh besar terkait SSRF. Attacker memanfaatkan celah SSRF pada infrastruktur cloud AWS lalu mengambil data pelanggan dalam jumlah besar. 

Dari situ banyak perusahaan mulai sadar bahwa satu request URL ternyata bisa membuka akses luas ke backend system.

2. Akses ke Jaringan Internal

SSRF sering berubah menjadi “jalan belakang” menuju jaringan internal perusahaan. Karena request berasal dari server internal, sistem target biasanya menganggap request tersebut aman.

Attacker lalu mencoba mengakses berbagai layanan privat seperti dashboard admin, Redis, Elasticsearch, Kubernetes API, Jenkins, sampai service monitoring internal.

Layanan tersebut sebenarnya aman dari internet publik. Namun SSRF membuat server menjadi perantara. Akhirnya attacker memperoleh akses tanpa perlu membobol firewall secara langsung.

Situasi seperti ini sering memicu pivot attack. Attacker masuk lewat satu aplikasi rentan, lalu bergerak menuju service lain dalam jaringan yang sama. Semakin kompleks arsitektur backend, semakin besar pula potensi kerusakannya.

Karena itu, SSRF sering dianggap berbahaya pada sistem microservices modern. Antar service biasanya saling terhubung lewat internal network. Celah kecil pada satu endpoint bisa membuka akses ke banyak sistem lain.

3. Port Scanning Internal

SSRF juga sering dipakai untuk memetakan struktur jaringan internal. Teknik ini mirip proses reconnaissance sebelum serangan utama berjalan.

Attacker akan mengirim request ke berbagai port internal seperti:

localhost:22

localhost:3306

localhost:6379

Lalu attacker memeriksa respons server. Dari situ mereka bisa mengetahui layanan aktif pada jaringan internal.

Port 22 biasanya menunjukkan SSH aktif. Port 3306 sering mengarah ke MySQL. Sedangkan port 6379 identik dengan Redis. Informasi seperti ini sangat berharga untuk tahap eksploitasi berikutnya.

Semakin lengkap peta jaringan yang attacker dapatkan, semakin mudah mereka menentukan target berikutnya. Bahkan blind SSRF pun tetap bisa membantu proses scanning lewat perbedaan respons, timeout, atau error tertentu.

Karena itu, banyak tim keamanan menganggap SSRF sebagai langkah awal menuju serangan yang lebih besar.

4. Remote Code Execution (RCE)

Dalam kondisi tertentu, SSRF bisa berkembang menjadi RCE atau Remote Code Execution. Artinya attacker berhasil menjalankan perintah pada server target.

Situasi ini biasanya terjadi ketika SSRF menyentuh service internal yang memiliki konfigurasi lemah atau celah tambahan. Misalnya Redis tanpa autentikasi, Jenkins terbuka, debug service aktif, atau internal API yang rentan command injection.

Attacker lalu mengirim payload tertentu melalui service tersebut. Setelah payload berhasil berjalan, kontrol server bisa berpindah sepenuhnya ke tangan attacker.

Tahap ini jelas jauh lebih berbahaya daripada sekadar membaca data. Karena attacker bisa memasang backdoor, mencuri file, mematikan service, bahkan mengambil alih seluruh infrastruktur backend.

RCE akibat SSRF memang tidak selalu terjadi. Namun kombinasi beberapa miskonfigurasi sering membuat skenario ini sangat mungkin muncul pada sistem besar.

5. Penyalahgunaan Resource Server

Blind SSRF sering dimanfaatkan untuk menyalahgunakan resource server korban. Attacker membuat server mengirim request massal ke target tertentu secara terus-menerus.

Teknik ini sering dipakai untuk:

• DDoS
• spam request
• probing jaringan
• bypass firewall
• validasi endpoint internal

Akibatnya server korban berubah menjadi alat serangan tanpa pemiliknya sadari.

Selain membebani bandwidth, aktivitas tersebut juga mengganggu performa server. Resource CPU dan koneksi jaringan bisa terkuras cukup cepat. Pada skala besar, operasional aplikasi ikut terdampak karena lonjakan outbound traffic.

Situasi makin rumit ketika aktivitas SSRF lolos dari monitoring. Tim administrator sering mengira lonjakan traffic berasal dari proses normal aplikasi.

Cara Mencegah Ancaman Server SSRF 

Meski berbahaya, tetap ada cara pencegahan yang bisa kamu lakukan, seperti: 

1. Validasi URL dengan Ketat

Jangan pernah langsung percaya pada input URL dari pengguna. Selalu lakukan validasi terhadap hostname, protocol, IP address, port, dan redirect.

Gunakan allowlist domain agar server hanya mengakses domain tertentu. Pendekatan ini jauh lebih aman daripada blacklist.

Karena attacker sering memakai trik encoding atau manipulasi DNS untuk melewati filter sederhana. Bahkan IP localhost bisa muncul dalam berbagai format unik seperti:

127.1

0x7f000001

2130706433

Karena itu, validasi URL perlu berjalan ketat sejak awal request masuk. 

2. Blokir Akses ke IP Internal

Server sebaiknya tidak memiliki akses bebas menuju internal subnet atau metadata cloud.

Blokir akses menuju:

• localhost
• loopback IP
• private subnet
• metadata endpoint
• internal service

Firewall dan network ACL sangat membantu untuk membatasi akses tersebut. Jadi meskipun SSRF berhasil muncul, attacker tetap sulit menjangkau resource sensitif.

3. Gunakan Network Segmentation

Pisahkan layanan publik dengan layanan internal. Frontend application sebaiknya tidak berada dalam jaringan yang sama dengan database atau internal API.

Segmentasi jaringan membuat attacker sulit bergerak ke sistem lain setelah menemukan satu celah SSRF. Dampaknya pun jadi lebih terbatas.

Konsep ini sangat penting pada arsitektur Kubernetes dan microservices modern.

Server Aman Butuh Infrastruktur Kencang dan Proteksi Stabil

SSRF sering memanfaatkan celah kecil pada server yang konfigurasi dan pengamanannya kurang optimal. 

Karena itu, performa server saja tidak cukup. Kamu juga perlu infrastruktur dengan isolasi resource jelas, kontrol jaringan ketat, dan proteksi berlapis agar risiko eksploitasi bisa ditekan sejak awal.

Untuk kebutuhan tersebut, VPS Hosting NVMe dari Biznet Gio Cloud cocok buat aplikasi modern yang butuh performa tinggi dan keamanan stabil. 

Server ini memakai SSD NVMe enterprise dengan IOPS hingga 80.000, vCPU dan RAM dedicated, plus Security Group untuk membatasi akses port sensitif dari luar. 

Infrastruktur HPE Gen11 dan AMD EPYC terbaru juga membantu workload backend tetap responsif saat traffic tinggi.

Kalau kamu butuh skala lebih besar, layanan VPS Server Biznet Gio menyediakan bandwidth gratis, anti-DDoS protection, instant snapshot backup, sampai fleksibilitas upgrade resource tanpa ribet migrasi server. 

Cocok untuk deployment aplikasi, API backend, container, atau environment testing yang butuh performa konsisten sekaligus kontrol keamanan lebih rapi.