TOP 10 OWASP - A10:2025 — Server-Side Request Forgery (SSRF) — Series Referensi Cybersecurity 2025 -2026

Catatan Editorial: Posisi SSRF di Edisi 2025

Di edisi OWASP Top 10:2021, SSRF masuk sebagai entri baru di posisi #10 — didorong bukan oleh data CVE historis melainkan oleh survei komunitas yang mengidentifikasinya sebagai ancaman yang sedang naik signifikan.

Di edisi 2025, SSRF diserap ke dalam A01 (Broken Access Control) — keputusan yang mencerminkan pemahaman bahwa SSRF pada dasarnya adalah masalah kontrol akses: server membuat request atas nama penyerang ke resource yang seharusnya tidak dapat diakses langsung dari internet. Penyatuan ini secara konseptual tepat namun tidak mengurangi bahayanya.

SSRF tetap mendapat artikel tersendiri dalam seri ini karena pola serangan, teknik eksploitasi, dan mitigasinya cukup distinct untuk dipahami secara mendalam — terutama dalam konteks cloud modern di mana dampaknya bisa sangat destruktif.

Apa itu Server-Side Request Forgery?

Server-Side Request Forgery (SSRF) adalah kerentanan di mana penyerang dapat memaksa server aplikasi untuk membuat HTTP request ke tujuan yang ditentukan oleh penyerang — baik ke internal network, cloud metadata service, atau sumber daya lain yang seharusnya tidak dapat diakses dari internet.

Kata kunci adalah "atas nama server". Penyerang tidak mengakses target secara langsung — mereka memanfaatkan server sebagai proxy tidak sah untuk mengakses resource di balik firewall yang seharusnya tidak dapat dijangkau dari luar.

Serangan normal (langsung):
Penyerang → [FIREWALL MEMBLOKIR] → Internal Resource

Serangan SSRF:
Penyerang → Server Aplikasi → [Firewall Mengizinkan] → Internal Resource
              (manipulasi URL input)

Dalam bahasa bisnis: ini adalah kondisi di mana penyerang dapat menggunakan server Anda sebagai agen untuk mengakses sistem internal, metadata cloud, layanan lain dalam jaringan, atau bahkan menyerang pihak ketiga — semua menggunakan identitas dan kepercayaan yang dimiliki server Anda.

Mengapa SSRF Berbahaya di Era Cloud?

SSRF bukan ancaman baru — ia sudah dikenal sejak lama. Namun relevansinya melonjak drastis seiring adopsi cloud karena satu fitur yang ada di semua cloud provider:

Cloud Instance Metadata Service (IMDS)

Setiap instance cloud (AWS EC2, Azure VM, GCP Compute Engine) memiliki endpoint metadata internal yang dapat diakses hanya dari dalam instance tersebut:

AWS: http://169.254.169.254/latest/meta-data/
Azure: http://169.254.169.254/metadata/instance
GCP: http://metadata.google.internal/computeMetadata/v1/

Endpoint ini menyediakan informasi tentang instance: nama, region, tags — dan yang paling kritis: IAM credentials sementara yang diberikan kepada instance.

Jika aplikasi yang berjalan di instance tersebut rentan terhadap SSRF, penyerang dapat:

Menggunakan SSRF untuk mengakses http://169.254.169.254/latest/meta-data/iam/security-credentials/
Mendapatkan AWS access key, secret key, dan session token sementara
Menggunakan credentials tersebut untuk mengakses seluruh layanan AWS yang memiliki izin untuk instance tersebut — S3 buckets, database, lambda functions, dll.

Inilah yang terjadi pada Capital One (2019) — satu SSRF pada WAF berhasil mengekspos credentials IAM yang kemudian digunakan untuk mengakses 100 juta catatan pelanggan dari S3.

Jenis-Jenis SSRF

1. Basic/In-Band SSRF

Respons dari request yang dipaksakan dikembalikan langsung dalam respons HTTP ke penyerang. Paling mudah dieksploitasi dan dideteksi.

Contoh skenario:

Fitur sah: aplikasi mengambil preview gambar dari URL yang diinput pengguna
Input sah:     https://example.com/image.jpg
Input berbahaya: http://169.254.169.254/latest/meta-data/

Server mengambil content dari URL tersebut dan mengirimkannya ke browser penyerang
→ Credentials cloud terekspos

2. Blind/Out-of-Band SSRF

Server membuat request ke target yang ditentukan penyerang, tetapi tidak mengembalikan respons ke penyerang. Penyerang hanya dapat mengonfirmasi keberhasilan melalui efek samping (DNS lookup, koneksi masuk ke server yang dikontrol penyerang).

Lebih sulit dieksploitasi namun masih berbahaya — dapat digunakan untuk:

Memetakan internal network (port scanning)
Memicu webhooks atau callback
Eksfiltrasi data melalui DNS

3. Semi-Blind SSRF

Penyerang mendapat respons parsial — misalnya status code (200 vs 404) tetapi tidak konten penuh. Cukup untuk mengonfirmasi keberadaan service internal.

4. SSRF untuk Lateral Movement

Setelah mendapatkan credentials dari metadata service, penyerang menggunakan credentials tersebut untuk bergerak lateral ke layanan lain dalam ekosistem cloud.

Titik Injeksi SSRF yang Umum

SSRF dapat muncul di manapun aplikasi menggunakan input pengguna untuk menentukan tujuan request:

URL parameters yang digunakan untuk fetch:

/api/preview?url=https://example.com
/api/webhook?callback=https://notify.service.com
/api/import?source=https://data.example.com/file.csv
/api/screenshot?page=https://target-site.com

File upload dengan referensi URL:

{"avatar_url": "https://..."}
{"document_link": "https://..."}

PDF/Image generators: Layanan yang mengkonversi URL ke PDF atau mengambil screenshot website — sangat rentan karena fungsinya memang membuat request ke URL eksternal.

Webhook registrations:

POST /api/webhooks
{"notification_url": "http://internal-service/admin"}

Server-side redirects: Aplikasi yang mengikuti redirect dari URL eksternal tanpa validasi dapat diarahkan ke resource internal melalui rantai redirect.

XML/JSON dengan URL references: Parsing XML yang mengandung URL references dapat memicu SSRF melalui DTD atau XML namespaces.

Dampak Bisnis

Credentials Theft dan Full Cloud Compromise

Skenario paling merusak: SSRF → Metadata Service → IAM Credentials → Akses penuh ke semua layanan cloud yang memiliki izin. Dari satu kerentanan, penyerang dapat mengakses seluruh infrastruktur cloud.

Internal Network Reconnaissance

Penyerang menggunakan server sebagai pivot point untuk memetakan layanan internal: database servers, admin interfaces, internal APIs, microservices — semua yang tidak dapat dijangkau dari internet langsung.

Bypass Firewall dan IP Allowlists

Layanan internal yang hanya mengizinkan koneksi dari IP server tertentu dapat diakses melalui SSRF karena request datang dari IP server yang dipercaya.

Data Exfiltration

Akses ke database internal, file storage, atau layanan lain yang mengandung data sensitif.

Port Scanning dan Service Discovery

Memetakan layanan internal yang kemudian menjadi target serangan lanjutan.

Kasus Nyata

Capital One (2019)

Insiden paling terkenal dan paling mahal yang melibatkan SSRF. Penyerang mengeksploitasi SSRF pada WAF yang dikonfigurasi dengan salah di lingkungan AWS Capital One. Melalui SSRF, penyerang mengakses Instance Metadata Service dan mendapatkan IAM role credentials. Dengan credentials tersebut, penyerang mengakses lebih dari 700 folder S3 yang mengandung data 100 juta nasabah. Denda: $80 juta. Total kerugian: ratusan juta dolar.

GitLab SSRF (CVE-2021-22214)

Kerentanan SSRF pada fitur import project GitLab memungkinkan akses ke layanan internal. Meski dampaknya terbatas oleh konfigurasi jaringan GitLab, ini menunjukkan betapa mudahnya SSRF muncul dalam fitur yang tampaknya sederhana.

Exchange Server SSRF (CVE-2021-26855 — ProxyLogon)

Komponen dari serangan ProxyLogon yang mengkompromikan ratusan ribu Exchange server adalah SSRF yang memungkinkan bypass autentikasi. Dieksploitasi secara masif oleh multiple APT groups.

Webhook Abuse via SSRF

Berbagai platform SaaS yang memiliki fitur webhook telah ditemukan rentan terhadap SSRF melalui registrasi webhook dengan URL internal. Penyerang memanfaatkan ini untuk mengakses internal services dari platform SaaS yang dipercaya.

Layanan Cloud Lokal Indonesia (Anonimisasi)

Dalam assessment keamanan terhadap beberapa platform SaaS berbasis cloud yang beroperasi di Indonesia, fitur "import dari URL" dan "screenshot halaman web" ditemukan rentan terhadap SSRF yang dapat digunakan untuk mengakses metadata AWS dan service internal.

Mitigasi: Pendekatan Berlapis

Layer 1: Validasi dan Filtering Input

Gunakan Whitelist, Bukan Blacklist:

# RENTAN: Blacklist yang mudah di-bypass
def is_safe_url(url):
    blocked = ['169.254.169.254', '127.0.0.1', 'localhost']
    return not any(b in url for b in blocked)
    # Bypass: http://169.254.169.254@safe.com, http://0x7f000001

# AMAN: Whitelist domain yang diizinkan
ALLOWED_DOMAINS = {'images.cdn.com', 'api.trusted-partner.com'}

def is_safe_url(url):
    parsed = urlparse(url)
    return (parsed.scheme in ('https',) and 
            parsed.hostname in ALLOWED_DOMAINS)

Resolve DNS Setelah Validasi: Validasi domain, kemudian resolve IP-nya, kemudian validasi lagi bahwa IP yang dihasilkan bukan IP private atau loopback. Waspadai DNS rebinding attacks di mana domain yang valid me-resolve ke IP private setelah validasi awal.

Layer 2: Network-Level Controls

Blokir Outbound Request ke IP Private di Firewall:

Blokir semua outbound request dari server aplikasi ke:
- 10.0.0.0/8 (private network)
- 172.16.0.0/12 (private network)
- 192.168.0.0/16 (private network)
- 127.0.0.0/8 (loopback)
- 169.254.0.0/16 (link-local / cloud metadata)
- ::1 (IPv6 loopback)
- fc00::/7 (IPv6 private)

Network Segmentation: Server yang perlu membuat outbound request hanya boleh berkomunikasi dengan endpoint yang spesifik — bukan seluruh internet.

Layer 3: Cloud-Specific Mitigations

Aktifkan IMDSv2 (AWS): IMDSv2 membutuhkan session-oriented request dengan token yang harus diminta terlebih dahulu — membuat SSRF sederhana tidak bisa langsung mengakses metadata.

# Paksa IMDSv2 pada instance baru
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxx \
  --http-tokens required \
  --http-endpoint enabled

Least Privilege IAM: Pastikan IAM role yang diberikan kepada instance hanya memiliki hak minimum yang diperlukan. Jika credentials dicuri melalui SSRF, minimal dampaknya terbatas.

Nonaktifkan Metadata Service Jika Tidak Diperlukan: Jika instance tidak memerlukan akses ke metadata service, nonaktifkan sepenuhnya.

Layer 4: Response Handling

Jangan Return Raw Response: Jika aplikasi perlu mengambil content dari URL eksternal, jangan kembalikan raw response kepada pengguna. Parse konten yang diperlukan saja dan kirimkan hanya bagian yang relevan.

Set Timeout yang Ketat: Batasi waktu tunggu untuk outbound request — mencegah abuse untuk port scanning (yang menggunakan timing sebagai sinyal).

Testing SSRF

Metode	Deskripsi
Manual — Burp Collaborator	Generate unique URL, sisipkan ke semua parameter, pantau DNS/HTTP callbacks
Manual — Internal IP Probing	Coba `127.0.0.1`, `localhost`, `169.254.169.254`, `10.0.0.1` di semua URL parameter
OWASP ZAP	Active scan mendeteksi pola SSRF umum
Nuclei Templates	Template SSRF yang menguji cloud metadata endpoints
SSRFmap	Tools otomatis untuk eksploitasi SSRF
Interactsh	Platform untuk mendeteksi out-of-band SSRF

Vendor & Solusi Relevan di Indonesia

Kategori	Vendor / Solusi	Kehadiran Indonesia
WAF / SSRF Protection	Palo Alto Networks	✅ Tier 1
WAF / SSRF Protection	Fortinet FortiWeb	✅ Tier 1
WAF / SSRF Protection	F5 Advanced WAF	✅ Tier 1
WAF / SSRF Protection	Akamai App & API Protector	✅ Tier 1
WAF / SSRF Protection	Cloudflare WAF	⚠️ Tier 2
Cloud Security (CSPM)	Palo Alto Prisma Cloud	✅ Tier 1
Cloud Security (CSPM)	Microsoft Defender for Cloud	✅ Tier 1
Cloud Security (CSPM)	Trend Micro Cloud One	✅ Tier 1
DAST Testing	OWASP ZAP	Open-source
DAST Testing	Burp Suite Pro	Self-service
Pentest Lokal	Packet Systems Indonesia, Xynexis, Defender ID	✅ Lokal