Menu Tutup

Server-side request forgery (SSRF)

Dalam artikel ini kita akan menjelaskan Server-side request forgery, menjelaskan beberapa contoh umum, dan menjelaskan cara menemukan dan memanfaatkan berbagai jenis kerentanan SSRF.

Apa itu SSRF?

Server-side request forgery (juga dikenal sebagai SSRF) adalah kerentanan keamanan web yang memungkinkan penyerang menginduksi aplikasi sisi server untuk membuat permintaan HTTP ke domain sewenang-wenang yang dipilih penyerang.

Dalam contoh SSRF yang khas, penyerang dapat menyebabkan server membuat koneksi kembali ke dirinya sendiri, atau ke layanan berbasis web lain dalam infrastruktur organisasi, atau ke sistem pihak ketiga eksternal.

Apa dampak serangan SSRF?

Serangan SSRF yang berhasil sering dapat mengakibatkan tindakan yang tidak sah atau akses ke data 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 melakukan eksekusi perintah sewenang-wenang.

Eksploitasi SSRF yang menyebabkan koneksi ke sistem pihak ketiga eksternal dapat mengakibatkan serangan seterusnya yang berbahaya yang tampaknya berasal dari organisasi yang menampung aplikasi rentan, yang mengarah pada kewajiban hukum potensial dan kerusakan reputasi.

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 menampung aplikasi, melalui antarmuka jaringan loopback. Ini biasanya melibatkan penyediaan URL dengan nama host seperti 127.0.0.1 (alamat IP yang dicadangkan yang menunjuk ke adaptor loopback) atau localhost (nama yang umum digunakan untuk adaptor yang sama).

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

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

BACA JUGA  Pengertian Bug Cross Site Scripting (XSS) Vulnerability

Dalam situasi ini, penyerang dapat memodifikasi 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

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

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

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

  • Pemeriksaan kontrol akses mungkin diterapkan di komponen lain yang berada di depan server aplikasi. Ketika koneksi dibuat kembali ke server itu sendiri, pemeriksaan dilewati.
  • Untuk tujuan pemulihan bencana, aplikasi mungkin memungkinkan akses administratif tanpa masuk, untuk setiap pengguna yang datang dari mesin lokal. Ini memberikan cara bagi administrator untuk memulihkan sistem jika mereka kehilangan kredensial mereka.
  • 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, dan karenanya mungkin tidak dapat dijangkau secara langsung oleh pengguna.

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

Serangan SSRF terhadap sistem back-end lainnya

Tipe 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 secara langsung dijangkau oleh pengguna. Sistem ini sering memiliki alamat IP pribadi yang tidak dapat dirute. Karena sistem back-end biasanya dilindungi oleh topologi jaringan, mereka sering memiliki postur keamanan yang lebih lemah. Dalam banyak kasus, sistem back-end internal mengandung fungsionalitas sensitif yang dapat diakses tanpa otentikasi oleh siapa saja yang dapat berinteraksi dengan sistem.

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

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

Mengurangi pertahanan SSRF yang umum

Adalah umum untuk melihat aplikasi yang mengandung perilaku SSRF bersama dengan pertahanan yang bertujuan mencegah eksploitasi berbahaya. Seringkali, pertahanan ini dapat dielakkan.

BACA JUGA  Cara hack Facebook terbaru (Hack akun fb target)

SSRF dengan filter input blacklist-based

Beberapa aplikasi memblokir input yang berisi nama host seperti 127.0.0.1 dan localhost, atau URL sensitif seperti / admin. Dalam situasi ini, Anda dapat menghindari filter menggunakan berbagai teknik:

  • Menggunakan representasi IP alternatif 127.0.0.1, seperti 2130706433, 017700000001, atau 127.1.
  • Mendaftarkan nama domain Anda sendiri yang berubah menjadi 127.0.0.1. Anda dapat menggunakan spoofed.burpcollaborator.net untuk tujuan ini.
  • Mengaburkan string yang diblokir menggunakan pengodean URL atau variasi kasus.

SSRF dengan filter input whitelist-based

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

Spesifikasi URL berisi sejumlah fitur yang mungkin diabaikan ketika menerapkan penguraian ad hoc dan validasi URL:

  • Anda dapat menanamkan kredensial di URL sebelum nama host, menggunakan karakter @. Sebagai contoh: https: // diharapkan-host @ evil-host.
  • Anda dapat menggunakan karakter # untuk menunjukkan fragmen URL. Sebagai contoh: https: // evil-host # expected-host.
  • Anda dapat memanfaatkan hierarki penamaan DNS untuk menempatkan input yang diperlukan ke dalam nama DNS berkualifikasi lengkap yang Anda kontrol. Misalnya: https: // terduga-host.evil-host.
  • Anda dapat menyandi URL karakter untuk membingungkan kode parsing URL. Ini sangat berguna jika kode yang mengimplementasikan filter menangani karakter yang disandikan URL secara berbeda dari kode yang melakukan permintaan HTTP back-end.
  • Anda dapat menggunakan kombinasi teknik-teknik ini bersama-sama.

Bypassing filter SSRF melalui open redirection

Kadang-kadang mungkin untuk menghindari segala jenis pertahanan berbasis filter dengan mengeksploitasi kerentanan pengalihan terbuka.

Dalam contoh SSRF sebelumnya, misalkan URL yang dikirimkan pengguna benar-benar divalidasi untuk mencegah eksploitasi berbahaya terhadap perilaku SSRF. Namun, aplikasi yang URL-nya diizinkan berisi kerentanan pengalihan terbuka. Asalkan API digunakan untuk membuat permintaan HTTP back-end mendukung pengalihan, Anda dapat membuat URL yang memenuhi filter dan menghasilkan permintaan yang dialihkan ke target back-end yang diinginkan.

Misalnya, anggap aplikasi berisi kerentanan pengalihan terbuka di mana URL berikut:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

mengembalikan pengalihan ke:

http://evil-user.net

Anda dapat memanfaatkan kerentanan pengalihan terbuka untuk memotong filter URL, dan mengeksploitasi kerentanan SSRF sebagai berikut:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

Eksploitasi SSRF ini berfungsi karena aplikasi pertama memvalidasi bahwa URL stockAPI yang disediakan berada di domain yang diizinkan, yang mana itu. Aplikasi kemudian meminta URL yang disediakan, yang memicu pengalihan terbuka. Ini mengikuti pengalihan, dan membuat permintaan ke URL internal yang dipilih penyerang.

BACA JUGA  Metode Social Engineering Attack yang digunakan Hacker

Blind SSRF vulnerabilities

Blind SSRF vulnerabilities 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.

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

Finding hidden attack surface for SSRF vulnerabilities

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

URL sebagian dalam permintaan

Terkadang, aplikasi hanya menempatkan nama host atau bagian dari jalur URL ke dalam parameter permintaan. Nilai yang dikirimkan kemudian dimasukkan ke 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 dimasukkannya URL yang mungkin diminta oleh parser data untuk format tersebut. Contoh nyata dari ini adalah format data XML, yang telah banyak digunakan dalam aplikasi web untuk mengirimkan data terstruktur dari klien ke server. Ketika suatu aplikasi menerima data dalam format XML dan mem-parsingnya, itu mungkin rentan terhadap injeksi XXE, dan pada gilirannya menjadi rentan terhadap SSRF melalui XXE.

SSRF melalui tajuk Referer

Beberapa aplikasi menggunakan perangkat lunak analitik sisi server yang melacak pengunjung. Perangkat lunak ini sering mencatat tajuk Referer dalam permintaan, karena ini menarik untuk melacak tautan masuk. Seringkali perangkat lunak analitik benar-benar akan mengunjungi URL pihak ketiga apa pun yang muncul di tajuk Referer. Ini biasanya dilakukan untuk menganalisis konten 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 Referer.

Tinggalkan Balasan