Pemalsuan permintaan sisi server

SSRF - (Server-side request forgery)

Pemalsuan Permintaan Sisi Server atau SSRF adalah kerentanan di mana penyerang memaksa server untuk melakukan permintaan atas namanya. Berikut adalah beberapa kasus di mana kita dapat menggunakan serangan ini.

Bayangkan bahwa penyerang menemukan kerentanan SSRF pada server. Misalkan server hanyalah Server Web di dalam jaringan yang luas. Jaringan ini juga berisi beberapa komputer dan server lain.

odimera.com

Pada bagian ini, kami akan menjelaskan:

- Apa itu pemalsuan permintaan sisi server,
- Beberapa contoh umum SSRF
- Cara menemukan dan mengeksploitasi berbagai jenis kerentanan SSRF.

Apa itu SSRF?

Pemalsuan permintaan sisi server (SSRF) adalah kerentanan keamanan web yang memungkinkan penyerang untuk mendorong aplikasi sisi server untuk membuat permintaan ke lokasi yang tidak diinginkan.

Dalam serangan SSRF yang khas, penyerang dapat menyebabkan server membuat koneksi ke layanan internal saja 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 mengeksploitasi kerentanan SSRF, penyerang mungkin dapat:

Pindai mesin lain di jaringan server rentan yang tidak dapat dia akses sebaliknya.
Lakukan serangan Remote File Inclusion.
Temukan layanan yang berjalan di setiap host jaringan.
Bypass Firewall dan memaksa server yang rentan melakukan permintaan jahat Anda.
Ambil file server (termasuk /etc/passwd dan banyak lagi).

Apa dampak serangan SSRF?

Serangan SSRF yang berhasil seringkali dapat mengakibatkan tindakan tidak sah atau akses ke data di dalam organisasi, baik dalam aplikasi yang rentan itu sendiri atau pada sistem back-end lain yang dapat berkomunikasi dengan aplikasi. Dalam beberapa situasi, kerentanan SSRF mungkin memungkinkan penyerang untuk melakukan eksekusi perintah arbitrer.

SSRF Vulnerability Server side request forgery

Gambar berasal dari: https://portswigger.net/web-security/ssrf

Eksploitasi SSRF yang menyebabkan koneksi ke sistem pihak ketiga eksternal dapat mengakibatkan serangan berbahaya selanjutnya yang tampaknya berasal dari organisasi yang menghosting aplikasi yang rentan.

Serangan SSRF umum

Serangan SSRF sering mengeksploitasi hubungan kepercayaan untuk meningkatkan serangan dari aplikasi yang rentan dan melakukan tindakan yang tidak sah. Hubungan kepercayaan ini mungkin ada dalam kaitannya dengan server itu sendiri, atau dalam kaitannya dengan sistem back-end lain dalam organisasi yang sama.

Serangan SSRF terhadap server itu sendiri

Dalam serangan SSRF terhadap server itu sendiri, penyerang menginduksi aplikasi untuk membuat permintaan HTTP kembali ke server yang menghosting aplikasi, melalui antarmuka jaringan loopback-nya. Ini biasanya akan melibatkan penyediaan URL dengan nama host seperti (alamat IP cadangan yang menunjuk ke adaptor loopback) atau (nama yang umum digunakan untuk adaptor yang sama). 127.0.0.1localhost

Misalnya, pertimbangkan aplikasi belanja yang memungkinkan pengguna melihat apakah suatu barang tersedia di toko tertentu. Untuk memberikan informasi stok, aplikasi harus menanyakan berbagai REST API back-end, tergantung pada produk dan toko yang dimaksud. 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

Hal ini menyebabkan server membuat permintaan ke URL yang ditentukan, mengambil status stok, dan mengembalikannya kepada pengguna.

Dalam situasi ini, penyerang dapat mengubah permintaan untuk menentukan URL lokal ke server itu sendiri. Misalnya:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

stockApi=http://localhost/admin

Di sini, server akan mengambil konten URL dan mengembalikannya ke pengguna. /admin

Sekarang tentu saja, penyerang bisa saja mengunjungi URL secara langsung. Tetapi fungsi administratif biasanya hanya dapat diakses oleh pengguna terautentikasi yang sesuai. Jadi penyerang yang hanya mengunjungi URL secara langsung tidak akan melihat sesuatu yang menarik. Namun, ketika permintaan ke URL berasal dari mesin lokal itu sendiri, kontrol akses normal dilewati. Aplikasi memberikan akses penuh ke fungsi administratif, karena permintaan tampaknya berasal dari lokasi tepercaya. /admin/admin

Mengapa aplikasi berperilaku seperti ini, dan secara implisit mempercayai permintaan yang berasal dari mesin lokal? Ini dapat timbul karena berbagai alasan:

Pemeriksaan kontrol akses mungkin diterapkan di komponen berbeda yang berada di depan server aplikasi. Ketika koneksi dibuat kembali ke server itu sendiri, pemeriksaan dilewati.
Untuk tujuan pemulihan bencana, aplikasi mungkin mengizinkan akses administratif tanpa masuk, ke pengguna mana pun yang datang dari mesin lokal. Ini menyediakan cara bagi administrator untuk memulihkan sistem jika mereka kehilangan kredensialnya. Asumsinya di sini adalah bahwa hanya pengguna yang sepenuhnya tepercaya yang akan datang langsung dari server itu sendiri.
Antarmuka administratif mungkin mendengarkan pada nomor port yang berbeda dari aplikasi utama, sehingga mungkin tidak dapat dijangkau langsung oleh pengguna.

Hubungan kepercayaan semacam ini, di mana permintaan yang berasal dari mesin lokal ditangani secara berbeda dari permintaan biasa, seringkali membuat SSRF menjadi kerentanan kritis.

Serangan SSRF terhadap sistem back-end lainnya

Jenis lain dari hubungan kepercayaan yang sering muncul dengan pemalsuan permintaan sisi server adalah di mana server aplikasi dapat berinteraksi dengan sistem back-end lain yang tidak dapat dijangkau secara langsung oleh pengguna. Sistem ini sering memiliki alamat IP pribadi yang tidak dapat dirutekan. Karena sistem back-end biasanya dilindungi oleh topologi jaringan, mereka sering memiliki postur keamanan yang lebih lemah. Dalam banyak kasus, sistem back-end internal berisi fungsionalitas sensitif yang dapat diakses tanpa otentikasi oleh siapa saja yang dapat berinteraksi dengan sistem.

Dalam contoh sebelumnya, misalkan ada antarmuka administratif di URL back-end . Di sini, penyerang dapat mengeksploitasi kerentanan SSRF untuk mengakses antarmuka administratif dengan mengirimkan permintaan berikut: https://192.168.0.68/admin

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin

SSRF dengan filter input berbasis daftar putih

Beberapa aplikasi hanya mengizinkan input yang cocok, dimulai dengan, atau berisi, daftar putih nilai yang diizinkan. Dalam situasi ini, Anda terkadang dapat menghindari filter dengan memanfaatkan inkonsistensi dalam penguraian URL.

Spesifikasi URL berisi sejumlah fitur yang dapat diabaikan saat menerapkan penguraian ad hoc dan validasi URL:

1. Anda dapat menyematkan kredensial di URL sebelum nama host, menggunakan karakter. Misalnya: @

https://expected-host:fakepassword@evil-host

2. Anda dapat menggunakan karakter untuk menunjukkan fragmen URL. Misalnya: #

https://evil-host#expected-host

3. Anda dapat memanfaatkan hierarki penamaan DNS untuk menempatkan input yang diperlukan ke dalam nama DNS yang sepenuhnya memenuhi syarat yang Anda kontrol. Misalnya:
https://expected-host.evil-host

Anda dapat mengkodekan karakter URL untuk membingungkan kode penguraian URL. Ini sangat berguna jika kode yang mengimplementasikan filter menangani karakter yang dikodekan URL secara berbeda dari kode yang melakukan permintaan HTTP back-end. Perhatikan bahwa Anda juga dapat mencoba karakter pengkodean ganda; beberapa server secara rekursif memecahkan kode URL input yang mereka terima, yang dapat menyebabkan perbedaan lebih lanjut.

Anda dapat menggunakan kombinasi teknik ini bersama-sama.

Kerentanan SSRF buta muncul ketika aplikasi dapat diinduksi untuk mengeluarkan permintaan HTTP back-end ke URL yang disediakan, tetapi respons dari permintaan back-end tidak dikembalikan dalam respons front-end aplikasi.

SSRF buta umumnya lebih sulit untuk dieksploitasi tetapi kadang-kadang dapat menyebabkan eksekusi kode jarak jauh penuh pada server atau komponen back-end lainnya.

Menemukan permukaan serangan tersembunyi untuk kerentanan SSRF

Banyak kerentanan pemalsuan permintaan sisi server relatif mudah dikenali, karena lalu lintas normal aplikasi melibatkan parameter permintaan yang berisi URL lengkap. Contoh lain dari SSRF lebih sulit ditemukan.

URL parsial dalam permintaan

Terkadang, aplikasi hanya menempatkan nama host atau bagian dari jalur URL ke parameter permintaan. Nilai yang dikirimkan kemudian dimasukkan sisi server ke dalam URL lengkap yang diminta. Jika nilainya mudah dikenali sebagai nama host atau jalur URL, maka permukaan serangan potensial mungkin terlihat jelas. Namun, eksploitasi sebagai SSRF penuh mungkin terbatas karena Anda tidak mengontrol seluruh URL yang diminta.
URL dalam format data
Beberapa aplikasi mengirimkan data dalam format yang spesifikasinya memungkinkan penyertaan URL yang mungkin diminta oleh pengurai data untuk format tersebut. Contoh nyata dari hal ini adalah format data XML, yang telah banyak digunakan dalam aplikasi web untuk mengirimkan data terstruktur dari klien ke server. Ketika sebuah aplikasi menerima data dalam format XML dan menguraikannya, aplikasi tersebut mungkin rentan terhadap injeksi XXE, dan pada gilirannya rentan terhadap SSRF melalui XXE. Kami akan membahas ini secara lebih rinci ketika kami melihat kerentanan injeksi XXE.
SSRF melalui header Referer
Beberapa aplikasi menggunakan perangkat lunak analisis sisi server yang melacak pengunjung. Perangkat lunak ini sering mencatat header Referer dalam permintaan, karena ini sangat menarik untuk melacak tautan masuk. Seringkali perangkat lunak analitik benar-benar akan mengunjungi URL pihak ketiga yang muncul di header Perujuk. Ini biasanya dilakukan untuk menganalisis isi situs rujukan, termasuk teks jangkar yang digunakan dalam tautan masuk. Akibatnya, header Referer sering mewakili permukaan serangan yang bermanfaat untuk kerentanan SSRF. Lihat Kerentanan SSRF buta untuk contoh kerentanan yang melibatkan header Perujuk.

Demikian Artikel kali ini tentang "SSRF Vulnerability - Pemalsuan permintaan sisi server" Semoga menambah pengetahuan anda.

#Programming #Hacking #Insight #odimera

SSRF Vulnerability - Pemalsuan permintaan sisi server