rincian serangan baru terhadap situs yang menggunakan model front-end-back-end, seperti situs yang berjalan melalui jaringan pengiriman konten, penyeimbang beban, atau proxy. Serangan tersebut memungkinkan, dengan mengirimkan permintaan tertentu, untuk memasukkan konten permintaan lain yang diproses di thread yang sama antara frontend dan backend. Metode yang diusulkan berhasil digunakan untuk mengatur serangan yang memungkinkan untuk mencegat parameter otentikasi pengguna layanan PayPal, yang membayar peneliti sekitar 40 ribu dolar sebagai bagian dari program untuk menginformasikan tentang adanya kerentanan yang belum ditambal. Serangan ini juga berlaku untuk situs yang menggunakan jaringan pengiriman konten Akamai.
Inti masalahnya adalah frontend dan backend sering kali memberikan tingkat dukungan yang berbeda untuk protokol HTTP, namun pada saat yang sama merangkum permintaan dari pengguna yang berbeda ke dalam saluran yang sama. Untuk menghubungkan permintaan penerimaan frontend dan permintaan pemrosesan backend, koneksi TCP yang berumur panjang dibuat, melalui mana permintaan pengguna ditransmisikan, ditransmisikan sepanjang rantai satu demi satu, dipisahkan melalui protokol HTTP. Untuk memisahkan permintaan, header "Panjang Konten" (menentukan ukuran total data dalam permintaan) dan ""(memungkinkan Anda mentransfer data dalam beberapa bagian, menentukan blok dengan ukuran berbeda dalam format "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").
Masalah muncul jika frontend hanya mendukung “Content-Length” tetapi mengabaikan “Transfer-Encoding: chunked” (misalnya, Akamai CDN melakukan ini) atau sebaliknya. Jika Transfer-Encoding: chunked didukung di kedua sisi, fitur implementasi parser header HTTP dapat digunakan untuk serangan (misalnya, ketika ujung depan mengabaikan baris seperti “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked ”, “Transfer-Encoding” :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" atau "Transfer-Encoding : chunked", dan backend berhasil memprosesnya).
Dalam hal ini, penyerang dapat mengirim permintaan yang berisi header "Panjang Konten" dan "Transfer-Encoding: terpotong", namun ukuran dalam "Panjang Konten" tidak sesuai dengan ukuran rantai terpotong, yang mana lebih kecil dari nilai sebenarnya. Jika frontend memproses dan meneruskan permintaan sesuai dengan "Panjang Konten" dan backend menunggu blok selesai berdasarkan "Transfer-Encoding: chunked", maka akhir data berdasarkan "Transfer-Encoding: chunked" akan ditentukan lebih awal dan sisa permintaan penyerang akan berada di awal permintaan berikutnya, yaitu. penyerang akan dapat melampirkan data sewenang-wenang ke awal permintaan orang lain yang dikirimkan berikutnya.
Untuk mengetahui permasalahan pada kombinasi frontend-backend yang digunakan, Anda dapat mengirimkan request seperti ini melalui frontend:
POSTING /tentang HTTP/1.1
Tuan rumah: example.com
Transfer-Encoding: terpotong
Content-Length: 4
1
Z
Q
Masalahnya muncul jika backend tidak segera memproses permintaan dan menunggu kedatangan blok data terpotong terakhir yang membatasi nol. Untuk pengecekan lebih lengkap sebuah utilitas khusus yang juga menguji kemungkinan metode untuk menyembunyikan header “Transfer-Encoding: chunked” dari frontend.
Melakukan serangan sebenarnya tergantung pada kemampuan situs yang diserang, misalnya saat menyerang aplikasi web Trello, Anda dapat mengganti awal permintaan (pengganti data seperti “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) dan mengirim pesan termasuk permintaan asli dari pengguna pihak ketiga dan Cookie otentikasi yang ditentukan di dalamnya. Untuk serangan terhadap saas-app.com, ternyata kode JavaScript dapat diganti sebagai respons dengan menggantinya ke salah satu parameter permintaan. Untuk serangan terhadap redhat.com, pengendali internal digunakan untuk mengalihkan ke situs web penyerang (permintaan dalam bentuk “POST /search?dest=../assets/idx?redir=//[email dilindungi]/HTTP/1.1").
Penggunaan metode jaringan pengiriman konten memungkinkan penggantian situs yang diminta dengan mengganti header “Host:”. Serangan ini juga dapat digunakan untuk meracuni konten sistem cache konten dan mengekstrak data rahasia yang di-cache. Puncak dari metode ini adalah pengorganisasian serangan terhadap PayPal, yang memungkinkan untuk mencegat kata sandi yang dikirim oleh pengguna selama otentikasi (permintaan iframe dimodifikasi untuk mengeksekusi JavaScript dalam konteks halaman paypal.com/us/gifts, misalnya CSP (Kebijakan Keamanan Konten) mana yang tidak diterapkan).
Menariknya, pada tahun 2005 ada teknik spoofing permintaan yang pada dasarnya serupa yang memungkinkan Anda melakukan spoofing data dalam cache proxy (Tomcat, Squid, mod_proxy) atau melewati pemblokiran firewall dengan menentukan beberapa permintaan “GET” atau “POST” dalam satu sesi HTTP.
Sumber: opennet.ru