Setelah beberapa waktu lalu kita membahas mengenai CSRF ( Cross-Site Request Forgery ) Sekarang kita akan membahas seputar SSRF. Emang apa bedanya bang?
Bedanya kalau serangan CSRF secara khusus menargetkan permintaan perubahan status, memaksa pengguna akhir untuk melakukan tindakan yang tidak diinginkan pada aplikasi web yang saat ini diautentikasi. Sementara SSRF adalah kerentanan di mana penyerang memaksa server untuk melakukan permintaan atas nama mereka.
Apa itu Server Side Request Forgery (SSRF) ?
Pemalsuan permintaan sisi server (juga dikenal sebagai SSRF) adalah kerentanan keamanan web yang memungkinkan penyerang mendorong aplikasi sisi server untuk membuat permintaan ke lokasi yang tidak diinginkan.
Server web menerima URL atau permintaan serupa dari komponen upstream dan mengambil konten URL ini, tetapi tidak cukup memastikan bahwa permintaan dikirim ke tujuan yang diharapkan.
Bagaimana SSRF Bisa Terjadi?
Dalam serangan SSRF biasa, penyerang dapat menyebabkan server membuat koneksi ke layanan internal saja di dalam infrastruktur organisasi. Dalam kasus lain, mereka mungkin dapat memaksa server untuk terhubung ke sistem eksternal yang sewenang-wenang, berpotensi membocorkan data sensitif seperti kredensial otorisasi.
Dengan menyediakan URL ke host atau port yang tidak terduga, penyerang dapat membuat server seolah-olah mengirim permintaan, kemungkinan melewati kontrol akses seperti firewall yang mencegah penyerang mengakses URL secara langsung. Server dapat digunakan sebagai proxy untuk melakukan pemindaian port host di jaringan internal, menggunakan URL lain seperti yang dapat mengakses dokumen di sistem (menggunakan file://), atau menggunakan protokol lain yang dapat memberikan kontrol lebih besar atas konten permintaan seperti gopher://, ldap://, tftp://, dict://, sftp:// hingga http://.
Bug Server- Side Request Forgery( SSRF) terjadi tiap kali aplikasi website mengambil sumber daya jarak jauh tanpa memvalidasi URL yang disediakan pengguna. Ini membolehkan penyerang guna memaksa aplikasi untuk mengirim permintaan yang dibuat ke tujuan yang tidak terduga, apalagi pada saat dilindungi oleh firewall, VPN, ataupun tipe lain dari daftar kontrol akses jaringan.
Serbuan pemalsuan permintaan sisi server( SSRF) adalah saat penyerang membuat permintaan HTTP berbahaya yang memicu permintaan lebih lanjut dari server kamu ke domain yang mereka seleksi. Kerentanan SSRF bisa digunakan untuk menyelidiki jaringan kamu ataupun digunakan untuk menyamarkan serbuan penolakan layanan terhadap pihak ketiga.
Terdapat banyak alasan server web kamu mungkin membuat permintaan HTTP keluar, termasuk memanggil layanan website pihak ketiga ataupun mengakses meta- data dari URL jarak jauh. Termasuk diantaranya :
- Memanggil API pihak ketiga sebagai tanggapan atas tindakan pengguna.
- Berkomunikasi dengan penyedia Single Sign-On (SSO).
- Menerapkan fungsi unggah gambar yang menerima URL, bukan file.
- Memeriksa URL validasi - misalnya, file skema yang dihosting yang dirujuk dalam dokumen XML.
- Mengakses meta-data grafik terbuka yang digunakan dalam menghasilkan pratinjau tautan.
Dalam beberapa skenario, domain URL akan diambil dari permintaan HTTP. Ini memungkinkan penyerang memicu permintaan HTTP ke domain arbitrer. Pengguna jahat akan mencoba menggunakan ini dalam serangan penolakan layanan terhadap target lain (yang akan kamu salahkan), dan untuk menyelidiki alamat IP internal di jaringan internal kamu yang tidak dimaksudkan untuk publik.
Bila server website kamu membuat permintaan HTTP ke domain arbitrer yang bisa dipilih oleh penyerang, kamu mungkin rentan terhadap Server side request forgery ( SSRF).
Serangan Lanjutan yang dapat dieksekusi dari SSRF
1. Denial of Service (dos)
2. Local File Inclusion (LFI)
3. Cross Site Scripting (XSS)
4. Remote Code Execution (RCE)
Contoh Serangan SSRF
Misalkan kamu menjalankan web media sosial yang menekan pengguna untuk berbagi tautan dan mendiskusikan berita terkini.
Web semacam ini umumnya menciptakan data pratinjau untuk tiap URL yang dibagikan pengguna, yang hendak dihasilkan dari meta- data di halaman jarak jauh. Hal ini kerap membutuhkan pembuatan permintaan HTTP dari server website tiap kali tautan dibagikan.
Hal ini memberi penyerang kesempatan untuk memicu permintaan HTTP dari server web kamu ke URL yang mereka pilih.
Salah satu risikonya adalah penyerang akan meluncurkan serbuan penolakan layanan pada pihak ketiga dengan memanfaatkan kamu selaku proxy- serangan yang hendak disalahkan atas kamu.
Dengan mengirim spam ke server kamu dengan permintaan untuk mengambil meta- data dari domain pihak ketiga, penyerang membanjiri situs website itu sembari bersembunyi di balik server website kamu.
Resiko yang lain yaitu penyerang bisa menyelidiki jaringan internal kamu dengan merangsang permintaan ke alamat IP individu.
Bila respons dari permintaan HTTP ini bocor- misalnya, dalam pesan kesalahan- penyerang apalagi bisa jadi membaca data dari penyimpanan informasi sensitif.
Contoh Sekenario SSRF lainnya serangan SSRF terhadap server itu sendiri :
Misalnya, mempertimbangkan aplikasi belanja yang memungkinkan pengguna melihat apakah suatu barang tersedia di toko tertentu. Untuk memberikan informasi stok, aplikasi harus menanyakan berbagai API REST back-end, bergantung pada produk dan toko yang bersangkutan.
Fungsi ini diimplementasikan dengan meneruskan URL ke titik akhir API back-end yang relevan melalui permintaan HTTP front-end. Jadi ketika pengguna melihat status stok untuk suatu item, browser mereka membuat permintaan seperti ini:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
Dalam situasi ini, penyerang dapat mengubah permintaan untuk menentukan URL lokal ke server itu sendiri. Sebagai contoh:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://localhost/admin
Sekarang tentu saja, penyerang bisa langsung mengunjungi URL /admin tersebut. Tetapi fungsi administratif biasanya hanya dapat diakses oleh pengguna terotentikasi yang sesuai. Jadi penyerang yang hanya mengunjungi URL secara langsung tidak akan melihat sesuatu yang menarik. Namun, ketika permintaan ke URL /admin berasal dari mesin lokal itu sendiri, kontrol akses normal akan dilewati. Aplikasi memberikan akses penuh ke fungsi administratif, karena permintaan tampaknya berasal dari lokasi tepercaya.
Melindungi Situs dari Server-side request forgery (SSRF)
Berikut beberapa cara yang mungkin dapat diterapkan untuk meminimalisir serangan SSRF:
1. Bangun Domain URL Di Server
Cara termudah untuk mengurangi kerentanan SSRF adalah dengan tidak pernah membuat permintaan HTTP ke nama domain yang diambil dari permintaan HTTP. Jika kamu memanggil Google Maps API dari server web kamu, misalnya, domain API harus didefinisikan dalam kode sisi server, bukan ditarik dari klien. Cara mudah untuk melakukannya adalah dengan menggunakan Google Maps SDK, yang terlihat seperti ini di Java:
DirectionsResult result =
DirectionsApi.newRequest(ctx)
.mode(com.google.maps.model.TravelMode.BICYCLING)
.avoid(
RouteRestriction.HIGHWAYS,
RouteRestriction.TOLLS,
RouteRestriction.FERRIES)
.region("au")
.origin("Sydney")
.destination("Melbourne")
.await();
2. Nonaktifkan URL Validasi Eksternal
Dokumen XML sering merujuk file skema yang dihosting di URL jarak jauh. Namun, secara umum, kamu harus tahu cara memvalidasi file XML yang diunggah sebelumnya. Jika kamu melakukan validasi dokumen XML di server kamu, pastikan itu bertentangan dengan file skema yang disimpan secara lokal, bukan diambil dari XML yang diunggah yang dapat dikontrol oleh penyerang.
Berikut cara menonaktifkan validasi skema eksternal dalam java.xml.validationpaket jika kamu menggunakan Java, misalnya:
SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
Schema schema = factory.newSchema();
Validator validator = schema.newValidator();
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
3. Hanya Lakukan Panggilan HTTP Keluar Atas Nama Pengguna Asli
Beberapa situs web memang perlu membuat permintaan ke URL pihak ketiga yang sewenang-wenang. Situs media sosial, misalnya, memungkinkan berbagi tautan web, dan sering kali akan menarik meta-data grafik terbuka dari URL tersebut untuk menghasilkan pratinjau tautan. Dalam kasus ini, kamu perlu melindungi diri dari serangan SSRF. Ini berarti kamu harus:
- Hanya buat permintaan HTTP keluar dari server kamu sebagai tanggapan atas tindakan oleh pengguna yang diautentikasi .
- Batasi jumlah tautan yang dapat dibagikan pengguna dalam jangka waktu tertentu, untuk menghindari penyalahgunaan.
- Pertimbangkan untuk membuat pengguna lulus uji CAPTCHA dengan setiap tautan yang mereka bagikan.
4. Validasi URL yang kamu Akses
Untuk mencegah penyerang menyelidiki jaringan kamu, kamu harus memastikan permintaan sisi server hanya dikirim ke URL yang dapat diakses publik. Untuk menegakkan ini, kamu harus:
- Bicaralah dengan tim jaringan kamu tentang membatasi server internal mana yang dapat dijangkau dari server web kamu.
- Validasi bahwa URL yang diberikan berisi domain web, bukan alamat IP.
- Larang URL dengan port non-stkamur.
- Pastikan semua URL diakses melalui HTTPS, dengan sertifikat yang valid.
Perhatikan bahwa penyerang yang kompeten akan dapat mengatur catatan DNS yang mengarah ke IP pribadi, jadi memvalidasi URL yang memiliki domain umumnya tidak cukup.
5. Simpan Daftar Blokir
kamu harus mempertahankan "daftar blokir" domain yang tidak akan pernah kamu akses dalam permintaan sisi server, baik dalam file konfigurasi atau dalam database. Ini akan membantu kamu untuk menghentikan permintaan nakal yang dipicu oleh penyerang, dan menghentikan upaya serangan penolakan layanan di jalurnya.
6. Mengurangi Pemalsuan Permintaan Sisi Server
Adalah umum untuk menerapkan ekspresi reguler dan daftar hitam sederhana ke input pengguna, untuk mengurangi SSRF dan serangan serupa. Namun, secara umum, daftar hitam adalah metode kontrol keamanan yang tidak efektif. Penyerang dapat dengan mudah menemukan cara untuk menyiasatinya. Misalnya, penjahat dunia maya dapat menggunakan layanan DNS wildcard, pengalihan HTTP, atau pengkodean IP alternatif.
7. Whitelist dan Resolusi DNS
Pendekatan yang solid untuk menjauhi SSRF adalah dengan memasukkan alamat IP ataupun nama DNS yang membutuhkan akses ke whitelist. Hanya saja bila pendekatan catatan putih tidak sesuai kamu wajib memakai blacklist. Sangat berarti kalau kamu mengotorisasi input pengguna secara efisien. Misalnya, jangan izinkan permintaan ke alamat IP individu yang tidak bisa dirutekan.
Dalam permasalahan Blacklist, strategi mitigasi yang pas akan berbeda sesuai dengan aplikasi. Dengan demikian, tidak terdapat revisi satu ukuran untuk semua untuk SSRF, sebab sangat tergantung pada tuntutan organisasi serta fungsionalitas aplikasi.
8. Penindakan Respon
Untuk menghentikan data respons supaya tidak sampai ke penjahat dunia maya, kamu wajib membenarkan kalau respons yang diterima cocok dengan apa yang diduga. Tanpa akun, badan respons mentah yang diterima dari permintaan yang diprakarsai oleh server tidak boleh ditransfer ke klien.
9. Nonaktifkan Skema URL yang Tidak Digunakan
Bila aplikasi kamu cuma mengkamulkan HTTPS ataupun HTTP guna mengawali permintaan, izinkan hanya skema URL ini. Dengan menonaktifkan skema URL yang tidak digunakan, kamu menolak kemampuan penyerang untuk memakai aplikasi untuk melakukan permintaan lewat skema yang berpotensi berbahaya, termasuk dict://, file://, serta gopher://.
10. Otentikasi pada Layanan Internal
Layanan semacam Redis, MongoDB, Elasticsearch, serta Memcached tidak meminta verifikasi secara default. Penjahat dunia maya bisa mendapatkan akses ke layanan tertentu tanpa verifikasi, memakai kerentanan SSRF. Jadi, untuk menegakkan keamanan aplikasi website, hendaknya izinkan verifikasi kapan pun kamu bisa, termasuk untuk layanan jaringan lokal.
SSRF Payload
Mungkin saja kalian bisa terbantu dengan beberapa payload untuk membypass beberapa filter waf di beberapa aplikasi yang kalian curigai memiliki celah SSRF.
Sekian sedikit tentang Mengenal Apa itu Server-side request forgery (SSRF) dan Bagaimana Bisa Terjadi? & Mitigasi dari SSRF, semoga membantu :D
