Widget HTML #1


Beranda / owasptop102025

A01:2025 Server-Side Request Forgery (SSRF).

webmaster

Ketika Server Dipaksa Menyerang Dirinya Sendiri

Dalam dunia keamanan aplikasi, tidak semua serangan dilakukan secara langsung oleh penyerang dari luar. Ada kalanya penyerang justru memanfaatkan server itu sendiri sebagai alat serangan. Inilah inti dari kerentanan yang dikenal sebagai Server-Side Request Forgery (SSRF), salah satu risiko penting yang kini digabungkan ke dalam kategori Broken Access Control pada OWASP Top 10 tahun 2025 .

SSRF menjadi semakin relevan di era arsitektur modern yang dipenuhi API, layanan mikro (microservices), cloud platform, dan integrasi antarsistem yang saling terhubung.

Apa Itu SSRF?

SSRF terjadi ketika penyerang berhasil memanipulasi server agar melakukan permintaan (request) yang seharusnya tidak pernah dilakukan. Permintaan ini bukan berasal dari browser pengguna, melainkan dari backend server itu sendiri.

Dalam kondisi normal, server hanya melakukan request ke tujuan yang telah dirancang. Namun pada SSRF, server “tertipu” sehingga:

  • Mengakses layanan internal
  • Memindai port internal
  • Mengambil data sensitif dari endpoint privat
  • Menghubungi API atau layanan yang tidak terekspos ke publik

Dengan kata lain, penyerang tidak menyerang langsung sistem internal, tetapi memaksa server menjadi perantara serangan .

Mengapa SSRF Sangat Berbahaya?

SSRF sangat berbahaya karena server biasanya memiliki hak akses yang jauh lebih besar dibandingkan pengguna biasa. Server dipercaya oleh sistem internal, sehingga permintaan yang datang “dari dalam” sering kali tidak diverifikasi seketat permintaan dari luar.

Akibatnya, penyerang bisa:

  • Mendapatkan informasi internal yang seharusnya tersembunyi
  • Mengakses metadata cloud
  • Menyentuh layanan sensitif seperti database, message queue, atau sistem manajemen internal

Semua ini dapat terjadi tanpa perlu autentikasi tambahan.

Kasus Nyata: SSRF di Layanan Microsoft Azure

Pada tahun 2023, SSRF menjadi sorotan besar setelah ditemukan kerentanan pada empat layanan Microsoft Azure, yaitu:

  • Azure Digital Twins
  • Azure Functions
  • Azure API Management
  • Azure Machine Learning

Dalam kasus ini, penyerang mampu:

  • Melakukan enumerasi port internal
  • Mengakses endpoint privat
  • Mengeksplorasi layanan internal yang seharusnya tidak bisa diakses dari luar

Kasus ini menunjukkan bahwa bahkan platform cloud berskala global pun tidak kebal terhadap SSRF, terutama ketika arsitektur layanan sangat kompleks dan saling terhubung .

SSRF Tidak Hanya Terjadi di Perusahaan Besar

SSRF bukan masalah eksklusif perusahaan besar. Dalam pengalaman yang dibagikan pada sesi ini, pembicara menemukan sebuah aplikasi yang secara tidak sengaja mengekspos internal URL. Dari celah kecil tersebut, ia dapat:

  • Memindai alamat IP internal
  • Mengumpulkan informasi infrastruktur
  • Memahami topologi sistem dari dalam

Semua itu terjadi hanya karena server mengizinkan request tanpa validasi yang memadai.

Bagaimana SSRF Bekerja?

Secara konsep, SSRF bekerja dengan cara:

  1. Aplikasi menerima input berupa URL, alamat IP, atau endpoint
  2. Input tersebut digunakan server untuk membuat request
  3. Penyerang memanipulasi input agar mengarah ke:
    • Internal IP (misalnya 127.0.0.1 atau alamat privat)
    • Metadata service cloud
    • Endpoint internal lain yang sensitif
  4. Server menjalankan request tersebut dan mengembalikan respons ke penyerang

Dalam sesi ini, SSRF dijelaskan melalui analogi yang membedakannya dari Cross-Site Request Forgery (CSRF):

  • CSRF terjadi di browser pengguna dan menyerang server
  • SSRF terjadi di backend, ketika satu server dipaksa menyerang server lain atau dirinya sendiri

SSRF berlangsung “di balik layar”, sehingga sering kali luput dari pengamatan .

Mengapa SSRF Digabungkan dengan Broken Access Control?

Pada OWASP Top 10 2025, SSRF tidak lagi berdiri sendiri, melainkan digabungkan ke dalam kategori Broken Access Control. Alasannya jelas: SSRF pada dasarnya adalah kegagalan sistem dalam membatasi akses server terhadap sumber daya internal.

Jika server boleh mengakses apa saja tanpa kontrol:

  • Tidak ada pembatasan tujuan request
  • Tidak ada validasi konteks
  • Tidak ada pemisahan zona kepercayaan

Maka SSRF menjadi pintu masuk yang sangat berbahaya.

Cara Bertahan dari SSRF

Transkrip ini menekankan bahwa pencegahan SSRF harus dilakukan secara berlapis. Beberapa langkah penting yang disarankan antara lain:

  1. Menonaktifkan HTTP Redirect Redirect dapat dimanfaatkan penyerang untuk mengalihkan request ke target internal yang tidak terduga.

  2. Sanitasi Input di Semua Level Validasi harus dilakukan baik di sisi klien maupun server. Input tidak boleh dipercaya begitu saja.

  3. Validasi dan Filter Request Secara Ketat Jangan biarkan server mengirim request ke tujuan acak. Gunakan allowlist daripada denylist.

  4. Batasi Informasi yang Dikembalikan ke Pengguna Respons dari server harus dianggap sensitif. Jangan mengembalikan detail internal ke klien.

  5. Anggap Semua Permintaan sebagai Tidak Terpercaya Bahkan jika request berasal dari pengguna internal atau eksekutif perusahaan, tetap lakukan verifikasi menyeluruh.

  6. Waspadai Inkonstistensi URL Perubahan URL antara waktu pengecekan dan penggunaan (TOCTOU) dapat memicu race condition yang berbahaya.

Pendekatan ini menegaskan prinsip utama keamanan modern: never trust, always verify .

Penutup: Ancaman Sunyi di Balik Arsitektur Modern

SSRF adalah contoh nyata bagaimana kerentanan tidak selalu datang dari kode yang kompleks, tetapi dari kepercayaan yang berlebihan. Ketika server dipercaya tanpa pembatasan yang jelas, ia bisa menjadi senjata bagi penyerang.

Di era cloud, API, dan AI, SSRF bukan lagi isu teknis kecil, melainkan risiko strategis. OWASP Top 10 2025 menempatkannya dalam konteks yang lebih luas—sebagai bagian dari kegagalan kontrol akses—agar organisasi benar-benar memahami bahwa keamanan bukan hanya soal siapa yang login, tetapi juga apa yang boleh dilakukan oleh sistem itu sendiri.

#owasptop10

#owasptop102025