Serangan ke atas sistem hadapan-belakang-belakang yang membolehkan kami menyatu dengan permintaan pihak ketiga

Terbongkar butiran serangan baharu pada tapak yang menggunakan model hadapan-belakang-belakang, seperti yang dijalankan melalui rangkaian penghantaran kandungan, pengimbang beban atau proksi. Serangan itu membenarkan, dengan menghantar permintaan tertentu, untuk menyelitkan ke dalam kandungan permintaan lain yang diproses dalam urutan yang sama antara bahagian hadapan dan bahagian belakang. Kaedah yang dicadangkan berjaya digunakan untuk mengatur serangan yang memungkinkan untuk memintas parameter pengesahan pengguna perkhidmatan PayPal, yang membayar penyelidik kira-kira 40 ribu dolar sebagai sebahagian daripada program untuk memaklumkan tentang kehadiran kelemahan yang tidak ditambal. Serangan itu juga boleh digunakan pada tapak yang menggunakan rangkaian penghantaran kandungan Akamai.

Inti masalahnya ialah bahagian hadapan dan bahagian belakang sering memberikan tahap sokongan yang berbeza untuk protokol HTTP, tetapi pada masa yang sama merangkum permintaan daripada pengguna yang berbeza ke dalam saluran yang sama. Untuk menyambung permintaan penerimaan bahagian hadapan dan permintaan pemprosesan bahagian belakang, sambungan TCP jangka panjang diwujudkan, yang melaluinya permintaan pengguna dihantar, dihantar sepanjang rantai satu demi satu, dipisahkan melalui protokol HTTP. Untuk memisahkan permintaan, tajuk "Panjang Kandungan" (menentukan jumlah saiz data dalam permintaan) dan "Transfer-Encoding: dipotong"(membolehkan anda memindahkan data dalam bahagian, menyatakan blok dengan saiz yang berbeza dalam format "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Masalah timbul jika bahagian hadapan hanya menyokong "Panjang Kandungan" tetapi mengabaikan "Pengekodan Pemindahan: chunked" (contohnya, Akamai CDN melakukan ini) atau sebaliknya. Jika Pemindahan-Pengekodan: chunked disokong pada kedua-dua belah pihak, ciri pelaksanaan penghurai pengepala HTTP boleh digunakan untuk serangan (contohnya, apabila bahagian hadapan mengabaikan baris seperti "Pengekodan Pemindahan: xchunked", "Pengekodan Pemindahan: digunting ”, “Pengekodan Pemindahan” :[tab]dipotong", "X: X[\n]Pengekodan Pemindahan: digolong", "Pengekodan Pemindahan[\n]: digunting" atau "Pengekodan Pemindahan : digunting", dan bahagian belakang berjaya memprosesnya).

Dalam kes ini, penyerang boleh menghantar permintaan yang mengandungi kedua-dua pengepala "Panjang Kandungan" dan "Pengekodan Pemindahan: terpotong", tetapi saiz dalam "Panjang Kandungan" tidak sepadan dengan saiz rantai terpotong, yang adalah lebih kecil daripada nilai sebenar. Jika bahagian hadapan memproses dan memajukan permintaan mengikut "Panjang Kandungan", dan bahagian belakang menunggu sehingga blok selesai berdasarkan "Pengekodan Pemindahan: digunting", maka penghujung data berdasarkan "Pengekodan Pemindahan: digunting" akan ditentukan lebih awal dan baki ekor permintaan penyerang akan berada pada permulaan permintaan seterusnya, i.e. penyerang akan dapat melampirkan data sewenang-wenangnya pada permulaan permintaan orang lain yang dihantar seterusnya.

Untuk menentukan masalah dalam gabungan frontend-backend yang digunakan, anda boleh menghantar permintaan seperti ini melalui frontend:

POST /tentang HTTP/1.1
Hos: example.com
Transfer-Encoding: dipotong
Panjang Kandungan: 4

1
Z
Q

Masalahnya wujud jika bahagian belakang tidak segera memproses permintaan dan menunggu ketibaan blok sempadan sifar akhir bagi data terpotong. Untuk semakan yang lebih lengkap disediakan utiliti khas yang juga menguji kaedah yang mungkin untuk menyembunyikan pengepala "Pengekodan Pemindahan: chunked" daripada bahagian hadapan.

Menjalankan serangan sebenar bergantung pada keupayaan tapak yang diserang, contohnya, apabila menyerang aplikasi web Trello, anda boleh menggantikan permulaan permintaan (ganti data seperti “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) dan hantar mesej termasuk permintaan asal pengguna pihak ketiga dan Kuki pengesahan yang dinyatakan di dalamnya. Untuk serangan ke atas saas-app.com, ternyata mungkin untuk menggantikan kod JavaScript dalam respons dengan menggantikannya dalam salah satu parameter permintaan. Untuk serangan ke atas redhat.com, pengendali dalaman telah digunakan untuk mengubah hala ke tapak web penyerang (permintaan borang "POST /search?dest=../assets/idx?redir=//[e-mel dilindungi]/ HTTP/1.1").

Menggunakan kaedah untuk rangkaian penghantaran kandungan membolehkan anda hanya menggantikan tapak yang diminta dengan menggantikan pengepala "Hos:". Serangan itu juga boleh digunakan untuk meracuni kandungan sistem caching kandungan dan mengekstrak data sulit yang dicache. Kemuncak kaedah itu ialah organisasi serangan ke atas PayPal, yang memungkinkan untuk memintas kata laluan yang dihantar oleh pengguna semasa pengesahan (permintaan iframe telah diubah suai untuk melaksanakan JavaScript dalam konteks halaman paypal.com/us/gifts, untuk CSP (Dasar Keselamatan Kandungan) yang tidak digunakan).

Menariknya, pada tahun 2005 ada dicadangkan teknik pemalsuan permintaan yang pada asasnya serupa yang membolehkan anda memalsukan data dalam proksi caching (Tomcat, squid, mod_proxy) atau memintas penyekatan tembok api dengan menyatakan beberapa permintaan "GET" atau "POST" dalam satu sesi HTTP.

Sumber: opennet.ru