Mengenal dan Memahami Celah Server Side Request Forgery

Mengenal dan Memahami Celah Server Side Request Forgery - Kali ini saya akan membahas sedikit tentang celah Server Side Request Forgery atau yang biasa disebut dengan SSRF. Server Side Request Forgery (SSRF) mengacu pada serangan di mana di penyerang dapat mengirim permintaan yang dibuat dari aplikasi web yang rentan.


Apa itu SSRF?
Server Side Request Forgery (SSRF) mengacu pada serangan di mana penyerang dapat mengirim permintaan yang dibuat dari aplikasi web yang rentan. SSRF biasanya digunakan untuk menargetkan sistem internal di belakang firewall yang biasanya tidak dapat diakses oleh penyerang dari jaringan eksternal. Selain itu, mungkin juga bagi penyerang untuk memanfaatkan SSRF untuk mengakses layanan dari server yang sama yang hanya bisa diakses dari antarmuka loopback (127.0.0.1).

Celah SSRF sendiri bisa dimanfaatkan untuk membaca file konfigurasi di sistem target seperti membaca file /etc/passwd. SSRF juga bisa dieksploitasi lebih lanjut hingga menjadi celah RCE.

Eksploitasi SSRF Melalui URL Scheme
Berikut beberapa url scheme yang dapat digunakan dalam ssrf.
  • file://
  • http://
  • dict://
  • sftp://
  • tftp://
  • ldap://
  • gopher://
Contoh SSRF
Berikut adalah kode PHP yang memiliki celah SSRF

<?php
if (isset($_GET['url'])){
$url = $_GET['url'];
$image = fopen($url, 'rb');
header("Content-Type: image/png");
fpassthru($image);
}

Oke, dalam contoh di atas, karena penyerang memiliki kontrol penuh terhadap parameter url, selain mampu membuat permintaan GET secara bebas ke situs web apa pun di internet, seorang penyerang juga dapat membuat permintaan ke sumber daya di server.

Sebagai contoh, mungkin bagi penyerang untuk mengakses layanan di localhost. Dalam contoh berikut, penyerang dapat membuat permintaan berikut pada Server HTTP Apache dengan mengaktifkan mod_status (diaktifkan secara default).
GET /?url=http://localhost/server-status HTTP/1.1
Host: example.com

Demikian pula, Server Side Request Forgery (SSRF) dapat digunakan untuk membuat permintaan ke sumber daya internal lain yang memiliki akses ke server web, tetapi tidak menghadap ke publik. Contoh seperti itu akan mengakses metadata instan di instance Amazon EC2 dan OpenStack. Layanan ini hanya tersedia untuk server dan jaringan internal. Seorang penyerang bahkan dapat berkreasi dengan SSRF dan menjalankan pemindaian port pada jaringan internal dengan pendekatan ini.
GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: example.com

Terlepas dari skema http:// dan https://, penyerang dapat memanfaatkan skema URL lain yang tidak difilter untuk mengakses file di sistem lokal atau di jaringan internal.
Contoh permintaan tersebut adalah yang berikut menggunakan file:/// skema URL.

GET /?url =file:///etc/passwd HTTP / 1.1
Host: example.com

Tergantung pada bagaimana aplikasi membuat permintaan, skema URL selain file dan HTTP dapat tersedia untuk digunakan penyerang. Misalnya, jika cURL digunakan untuk membuat permintaan (contoh di atas menggunakan fopen() untuk membuat permintaan), kalian dapat menggunakan skema URL dict untuk membuat permintaan ke host mana pun di port mana pun dan mengirim data khusus.
GET /?url = dict://localhost:11211/stat HTTP / 1.1
Host: example.com

Permintaan di atas akan menyebabkan aplikasi untuk terhubung ke localhost pada port 11211 dan mengirim string "stat". Port 11211 adalah port default yang digunakan oleh Memcached, yang biasanya tidak terekspos.

Menanggulangi Serangan SSRF
Whitelist dan resolusi DNS
Menerapkan simple blacklist atau regex langsung pada masukan pengguna untuk memfilter alamat IP atau domain mana yang dapat membuat permintaan adalah cara yang buruk untuk dilakukan ketika kalian ingin menangkal serangan SSRF.

Secara umum, blacklist adalah kontrol keamanan yang buruk karena akan selalu ada bypass yang tidak dibayangkan oleh pengembang. Dalam hal ini, bypass oleh penyerang semudah menggunakan HTTP redirect, layanan DNS wildcard seperti xip.io atau bahkan alternatif pengkodean IP.

Sebaliknya, cara paling ampuh untuk menangani SSRF adalah dengan memasukkan nama DNS atau alamat IP ke whitelist yang perlu diakses oleh aplikasi. Jika whitelist dirasa kurang cocok dengan aplikasi yang sedang kalian bangun, kalian bisa menggunakan blacklist, namun tentu saja harus sering update sehingga tidak mudah dibypass.

Penanganan Respon
Memastikan bahwa respon yang diterima oleh remote server adalah apa yang diharapkan oleh server adalah penting untuk mencegah data respon yang tak terduga bocor ke penyerang. Penting untuk diingat, dalam keadaan apa pun, respon raw dari permintaan yang dikirim oleh server untuk tidak dikirim ke klien.

Nonaktifkan skema URL yang tidak digunakan
Jika aplikasi Anda hanya menggunakan HTTP atau HTTPS untuk membuat permintaan, hanya izinkan skema URL tersebut. Menonaktifkan skema URL yang tidak digunakan akan mencegah aplikasi web membuat permintaan menggunakan skema URL yang berpotensi berbahaya seperti file:///, dict://, ftp:// dan gopher: //.

Otentikasi pada Layanan Internal
Layanan seperti Memcached, Redis, Elasticsearch dan MongoDB tidak memerlukan otentikasi secara default. SSRF bisa memberikan penyerang dengan kesempatan untuk mengakses beberapa layanan ini tanpa otentikasi. Oleh karena itu, yang terbaik adalah mengaktifkan otentikasi sebagai mekanisme pertahanan lain.

Contoh WriteUp Bug Bounty SSRF
  • https://hackerone.com/reports/223203
  • https://hackerone.com/reports/271224
  • https://hackerone.com/reports/341876
Contoh Eksploitasi SSRF pada Situs Penyedia Web Proxy

Oke mungkin itu yang bisa saya sampaikan, jika ada yang kurang jelas silahkan ditanyakan.
Referensi:
https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/