Server-side request forgery (SSRF)

Di bagian ini, kami akan menjelaskan apa itu pemalsuan permintaan sisi server, menjelaskan beberapa contoh umum, dan menjelaskan cara menemukan dan mengeksploitasi berbagai jenis kerentanan SSRF.

What is SSRF?

Pemalsuan permintaan sisi server (juga dikenal sebagai SSRF) adalah kerentanan keamanan web yang memungkinkan penyerang membujuk aplikasi sisi server untuk membuat permintaan HTTP ke domain sewenang-wenang yang dipilih penyerang.

Dalam contoh SSRF biasa, penyerang dapat menyebabkan server membuat sambungan kembali ke dirinya sendiri, atau ke layanan berbasis web lainnya dalam infrastruktur organisasi, atau ke sistem pihak ketiga eksternal.

What is the impact of SSRF attacks?

Serangan SSRF yang berhasil sering kali dapat mengakibatkan tindakan tidak sah atau akses ke data dalam organisasi, baik dalam aplikasi yang rentan itu sendiri atau pada sistem back-end lain yang dapat digunakan untuk berkomunikasi dengan aplikasi tersebut. 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 selanjutnya yang berbahaya yang tampaknya berasal dari organisasi yang menghosting aplikasi yang rentan, yang mengarah pada potensi kewajiban hukum 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 menghosting aplikasi, melalui antarmuka jaringan loopbacknya. Ini biasanya akan melibatkan penyediaan URL dengan nama host seperti 127.0.0.1 (alamat IP yang dicadangkan yang mengarah ke adaptor loopback) atau localhost (nama yang umum digunakan untuk adaptor yang sama).

Misalnya, pertimbangkan aplikasi belanja yang memungkinkan pengguna melihat apakah suatu item tersedia di toko tertentu. Untuk menyediakan informasi stok, aplikasi harus menanyakan berbagai API REST back-end, bergantung pada produk dan penyimpanan yang dimaksud. Fungsi ini diimplementasikan dengan meneruskan URL ke endpoint API back-end yang relevan melalui permintaan HTTP front-end. Jadi ketika pengguna melihat status stok suatu barang, 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.

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

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

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

Mengapa aplikasi berperilaku seperti ini, dan secara implisit mempercayai permintaan yang datang dari mesin lokal? Ini bisa muncul 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 komputer lokal. Ini memberikan cara bagi administrator untuk memulihkan sistem jika mereka kehilangan kredensial mereka. Asumsinya di sini adalah bahwa hanya pengguna 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 secara langsung oleh pengguna.

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

SSRF attacks against other back-end systems

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

Dalam contoh sebelumnya, misalkan ada antarmuka administratif di URL back-end https://192.168.0.68/admin. Di sini, penyerang dapat memanfaatkan 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

Mengakali pertahanan SSRF umum

Merupakan hal yang umum untuk melihat aplikasi yang berisi perilaku SSRF bersama dengan pertahanan yang ditujukan untuk mencegah eksploitasi jahat. Seringkali, pertahanan ini dapat dielakkan.

SSRF with blacklist-based input filters

Beberapa aplikasi memblokir input yang berisi nama host seperti 127.0.0.1 dan localhost, atau URL sensitif seperti / admin. Dalam situasi ini, Anda sering kali 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 menghasilkan 127.0.0.1. Anda dapat menggunakan spoofed.burpcollaborator.net untuk tujuan ini.
Obfuscating diblokir string menggunakan URL encoding atau variasi kasus.

SSRF with whitelist-based input filters

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

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

Anda dapat menyematkan kredensial di URL sebelum nama host, menggunakan karakter @. Misalnya: https: // expected-host @ evil-host.
Anda dapat menggunakan karakter # untuk menunjukkan fragmen URL. Misalnya: https: // evil-host # expected-host.
Anda dapat memanfaatkan hierarki penamaan DNS untuk menempatkan masukan yang diperlukan ke dalam nama DNS yang sepenuhnya memenuhi syarat yang Anda kontrol. Misalnya: https: //expected-host.evil-host.
Anda dapat menyandikan URL karakter untuk mengacaukan kode penguraian URL. Ini sangat berguna jika kode yang menerapkan filter menangani karakter yang dikodekan URL secara berbeda dari kode yang melakukan permintaan HTTP back-end.
Anda dapat menggunakan kombinasi dari teknik ini bersama-sama.

Bypassing SSRF filters via open redirection

Terkadang mungkin untuk menghindari segala jenis pertahanan berbasis filter dengan mengeksploitasi kerentanan pengalihan terbuka.

Dalam contoh SSRF sebelumnya, misalkan URL yang dikirimkan pengguna divalidasi secara ketat untuk mencegah eksploitasi berbahaya dari perilaku SSRF. Namun, aplikasi yang URL-nya diizinkan berisi kerentanan pengalihan terbuka. Asalkan API yang 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, 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 melewati filter URL, dan memanfaatkan 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 kali memvalidasi bahwa URL stockAPI yang disediakan ada di domain yang diizinkan, yang memang demikian. Aplikasi kemudian meminta URL yang disediakan, yang memicu pengalihan terbuka. Ini mengikuti pengalihan, dan membuat permintaan ke URL internal yang dipilih penyerang.

Partial URLs in requests

Terkadang, aplikasi hanya menempatkan nama host atau bagian dari jalur URL ke dalam parameter permintaan. Nilai yang dikirimkan kemudian dimasukkan sisi server ke dalam URL lengkap yang diminta. Jika nilainya langsung dikenali sebagai nama host atau jalur URL, maka potensi serangan yang muncul mungkin terlihat jelas. Namun, eksploitasi sebagai SSRF penuh mungkin terbatas karena Anda tidak mengontrol seluruh URL yang diminta.

URLs within data formats

Beberapa aplikasi mengirimkan data dalam format yang spesifikasinya memungkinkan penyertaan URL yang mungkin diminta oleh pengurai 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 aplikasi menerima data dalam format XML dan mem-parsingnya, itu mungkin rentan terhadap injeksi XXE, dan pada gilirannya menjadi rentan terhadap SSRF melalui XXE. Kami akan membahas ini lebih detail saat kami melihat kerentanan injeksi XXE.

SSRF via the Referer header

Beberapa aplikasi menggunakan perangkat lunak analitik sisi server yang melacak pengunjung. Perangkat lunak ini sering mencatat tajuk Perujuk dalam permintaan, karena ini khusus untuk melacak tautan masuk. Seringkali perangkat lunak analitik benar-benar akan mengunjungi URL pihak ketiga yang muncul di tajuk Perujuk. Ini biasanya dilakukan untuk menganalisis konten situs perujuk, termasuk teks tautan yang digunakan dalam tautan masuk. Akibatnya, tajuk Perujuk sering kali mewakili permukaan serangan yang bermanfaat untuk kerentanan SSRF. Lihat Kerentanan SSRF Buta untuk contoh kerentanan yang melibatkan header Referer.

Cari Blog Ini

KUHUKSERV