Table of contents
Open Table of contents
HTTP Request Queue Desynchronisation
Pertama-tama, teknik ini menyalahgunakan kerentanannya HTTP Request Smuggling, jadi Anda perlu mengetahui apa itu:
Perbedaan utama antara teknik ini dan HTTP Request smuggling biasa adalah bahwa sebagai gantinya menyerang permintaan korban dengan menambahkan awalan padanya, kita akan membocorkan atau memodifikasi respons yang diterima korban. Ini dilakukan dengan, alih-alih mengirimkan 1 permintaan dan setengah untuk menyalahgunakan HTTP Request smuggling, mengirimkan 2 permintaan lengkap untuk menyelaraskan antrean respons proxy.
Ini karena kita akan dapat menyelaraskan antrean respons sehingga respons dari permintaan sah korban dikirimkan kepada penyerang, atau dengan menyuntikkan konten yang dikendalikan penyerang dalam respons ke korban.
HTTP Pipeline Desync
HTTP/1.1 memungkinkan untuk meminta sumber daya yang berbeda tanpa perlu menunggu sumber daya sebelumnya. Oleh karena itu, jika ada proxy di tengah, tugas proxy adalah mempertahankan keselarasan permintaan yang dikirimkan ke backend dan respons yang datang dari sana.
Namun, ada masalah dalam menyelaraskan antrean respons. Jika seorang penyerang mengirimkan serangan HTTP Response smuggling dan respons untuk permintaan awal dan permintaan yang diselundupkan segera dijawab, respons yang diselundupkan tidak akan dimasukkan ke dalam antrean respons korban tetapi akan langsung dibuang sebagai kesalahan.
Oleh karena itu, diperlukan agar permintaan yang diselundupkan memerlukan lebih banyak waktu untuk diproses di dalam server backend. Oleh karena itu, pada saat permintaan yang diselundupkan diproses, komunikasi dengan penyerang akan selesai.
Jika dalam situasi ini korban telah mengirimkan permintaan dan permintaan yang diselundupkan dijawab terlebih dahulu sebelum permintaan yang sah, maka respons yang diselundupkan akan dikirimkan kepada korban. Oleh karena itu, penyerang akan mengendalikan permintaan “yang dilakukan” oleh korban.
Selain itu, jika penyerang kemudian melakukan permintaan dan respons yang sah untuk permintaan korban dijawab terlebih dahulu sebelum permintaan penyerang, maka respons kepada korban akan dikirimkan kepada penyerang, mencuri respons yang seharusnya untuk korban (yang dapat berisi, misalnya, header Set-Cookie).
Multiple Nested Injections
Perbedaan menarik lainnya dengan HTTP Request Smuggling biasa adalah bahwa, dalam serangan smuggling biasa, tujuan adalah untuk memodifikasi awal permintaan korban sehingga melakukan aksi yang tidak terduga. Dalam serangan HTTP Response smuggling, karena Anda mengirimkan permintaan lengkap, Anda bisa menyuntikkan dalam satu payload puluhan respons yang akan menyelaraskan puluhan pengguna yang akan menerima respons yang disuntikkan.
Selain bisa mendistribusikan lebih mudah puluhan eksploitasi di antara pengguna yang sah, ini juga bisa digunakan untuk menyebabkan DoS pada server.
Exploit Organisation
Seperti yang dijelaskan sebelumnya, untuk menyalahgunakan teknik ini, diperlukan agar pesan pertama yang diselundupkan ke server memerlukan waktu lama untuk diproses.
Permintaan yang memakan waktu ini cukup jika kita hanya ingin mencoba mencuri respons korban. Tetapi jika Anda ingin melakukan eksploitasi yang lebih kompleks, ini akan menjadi struktur umum untuk eksploitasi.
Pertama-tama permintaan awal yang menyalahgunakan HTTP Request smuggling, kemudian permintaan yang memakan waktu dan kemudian 1 atau lebih permintaan payload yang responsnya akan dikirimkan ke korban.
Menyalahgunakan HTTP Response Queue Desynchronisation
Menangkap permintaan pengguna lain
Seperti halnya payload HTTP Request Smuggling yang dikenal, Anda dapat mencuri permintaan korban dengan satu perbedaan penting: Dalam hal ini Anda hanya perlu mengirimkan konten yang akan tercermin dalam respons, tanpa perlu penyimpanan permanen.
Pertama, penyerang mengirimkan payload yang berisi permintaan POST final dengan parameter yang tercermin di akhir dan sebuah Content-Length besar
Kemudian, setelah permintaan awal (biru) telah diproses dan selama permintaan sleepy sedang diproses (kuning), permintaan berikutnya yang datang dari korban akan ditambahkan dalam antrean tepat setelah parameter yang tercermin:
Kemudian, korban akan menerima respons untuk permintaan sleepy dan jika dalam waktu yang sama penyerang mengirim permintaan lain, respons dari permintaan konten yang tercermin akan dikirimkan kepadanya.
Response Desynchronisation
Hingga saat ini, kita telah belajar bagaimana menyalahgunakan serangan HTTP Request Smuggling untuk mengendalikan permintaan yang respons nya akan diterima oleh klien dan bagaimana Anda kemudian bisa mencuri respons yang dimaksudkan untuk korban.
Namun, masih mungkin untuk menyelaraskan lebih jauh respons.
Ada permintaan menarik seperti HEAD request yang ditentukan untuk tidak memiliki konten dalam tubuh respons dan yang harus (harus) memuat Content-Length dari permintaan seolah itu adalah GET request.
Oleh karena itu, jika penyerang menyuntikkan HEAD request, seperti pada gambar ini:
Maka, setelah permintaan biru dijawab kepada penyerang, permintaan korban berikutnya akan dimasukkan ke dalam antrean:
HEAD /HelloWorld HTTP/1.1
Host: rentan.com
GET /HelloWorld HTTP/1.1
Host: rentan.com
GET /pageapapun HTTP/1.1
Host: rentan.com
Kemudian, korban akan menerima respons dari permintaan HEAD, yang akan mengandung Content-Length tetapi tidak ada konten sama sekali. Oleh karena itu, proxy tidak akan mengirimkan respons ini kepada korban, tetapi akan menunggu beberapa konten, yang sebenarnya akan menjadi respons untuk permintaan kuning (juga disuntikkan oleh penyerang):
Kebingungannya Konten
Mengikuti contoh sebelumnya, mengetahui bahwa Anda bisa mengendalikan tubuh dari permintaan yang responsnya akan diterima oleh korban dan bahwa respons HEAD biasanya mengandung dalam headernya Content-Type dan Content-Length, Anda bisa mengirim permintaan seperti berikut untuk menyebabkan XSS pada korban tanpa halaman tersebut rentan terhadap XSS:
Keracunan Cache
Menyalahgunakan serangan desinkronisasi respons yang telah dibahas sebelumnya mengenai Kebingungannya Konten, jika cache menyimpan respons dari permintaan yang dilakukan oleh korban dan respons ini adalah respons yang disuntikkan yang menyebabkan XSS, maka cache tersebut akan teracuni.
Permintaan berbahaya yang mengandung payload XSS:
Respons berbahaya kepada korban yang mengandung header yang menunjukkan ke cache untuk menyimpan respons:
Perhatikan bahwa dalam kasus ini jika “korban” adalah penyerang, maka dia sekarang dapat melakukan keracunan cache pada URL mana pun karena dia dapat mengendalikan URL yang akan disimpan di cache dengan respons berbahaya.
Penipuan Web Cache
Serangan ini mirip dengan yang sebelumnya, tetapi alih-alih menyuntikkan payload di dalam cache, penyerang akan menyimpan informasi korban di dalam cache:
Response Splitting
Tujuan dari serangan ini adalah untuk menyalahgunakan lagi desinkronisasi respons agar proxy mengirimkan respons yang sepenuhnya dibuat oleh penyerang.
Untuk mencapai ini, penyerang perlu menemukan endpoint aplikasi web yang memantulkan beberapa nilai di dalam respons dan mengetahui panjang konten dari respons HEAD.
Dia akan mengirimkan eksploitasi seperti:
Setelah permintaan pertama diselesaikan dan dikirimkan kembali kepada penyerang, permintaan korban ditambahkan ke dalam antrean:
Korban akan menerima sebagai respons respons HEAD + konten dari respons permintaan kedua (yang mengandung sebagian data yang dipantulkan):
Namun, perhatikan bagaimana data yang dipantulkan memiliki ukuran sesuai dengan Content-Length dari respons HEAD yang menghasilkan respons HTTP yang valid di antrean respons.
Oleh karena itu, permintaan berikutnya dari korban kedua akan menerima sebagai respons sesuatu yang sepenuhnya dibuat oleh penyerang. Karena respons sepenuhnya dibuat oleh penyerang, dia juga bisa membuat proxy menyimpan respons di cache.