Bug HTTP Request Smuggling dan Antisipasinya - CRUDPRO
Home  ›  WebSecurity

Bug HTTP Request Smuggling dan Antisipasinya

Written By Agus Handi Prayitna Wednesday, April 13, 2022

Pada kali ini saya akan membahas HTTP Request Smuggling yang pada pembahasan sebelumnya yang terdapat pada poin-poin kerentanan pada HTTP Host Header, oke langsung saja pada pembahasannya

Apa itu HTTP Request Smuggling?

HTTP Request Smuggling mengeksploitasi inkonsistensi dalam menguraikan request HTTP yang tidak sesuai dengan RFC melalui dua perangkat HTTP (biasanya server back-end dan firewall atau proxy front-end yang mendukung HTTP). Proses HTTP Request Smuggling dilakukan dengan membuat beberapa request HTTP khusus yang menyebabkan dua entitas target menampilkan dua kumpulan request yang berbeda.

Header HTTP menyediakan dua cara berbeda untuk menentukan di mana request berakhir. Header Transfer-Encoding dan Content-Length header. Kerentanan HTTP Request Smuggling terjadi ketika penyerang mengirim kedua header dalam satu request. Ini dapat menyebabkan server front-end atau server back-end salah menafsirkan request dan meneruskan query HTTP yang berbahaya.

Dengan mengklaim kerentanan smuggling, penjahat dunia maya dapat menghindari langkah-langkah keamanan, mendapatkan akses ke informasi sensitif, dan secara langsung membahayakan berbagai pengguna aplikasi. Ini juga dapat digunakan untuk eksploitasi sekunder seperti bypass firewall, partial cache poisoning, dan skrip lintas situs (XSS).

Cara kerja HTTP Request Smuggling

Apa implikasi dari serangan HTTP Request Smuggling?

Jika penyerang berhasil menjalankan serangan request smuggling, penyerang melewati kontrol keamanan internal dan menyuntikkan request HTTP berbahaya ke server web. Ini memungkinkan penyerang untuk:

  • Dapatkan akses ke sumber daya yang dilindungi seperti konsol manajemen
  • Dapatkan akses ke data sensitif
  • Sesi pembajakan pengguna web
  • Luncurkan serangan skrip lintas situs (XSS) tanpa perlu tindakan pengguna
  • Lakukan pembajakan kredensial

Contoh HTTP Request Smuggling

Sebagian besar serangan HTTP Request Smuggling mengeksploitasi kelemahan dalam content length (CL), Transfer Encoding (TE), atau keduanya. Tiga metode serangan utama dikenal sebagai "CL.TE". Ini berarti bahwa serangan itu mengeksploitasi content length di ujung depan dan mentransfer encoding di ujung belakang. Penyalahgunaan ganda penyandian transfer di frontend dan backend.

Kerentanan CL.TE (Content-Length.Transfer-Encoding)

Serangan Smuggling pada request HTTP CL.TE mengasumsikan bahwa server front-end menimpa header Content-Length dan server back-end menimpa header Transfer-Encoding.

Serangan dilakukan sebagai berikut. Bagian pertama dari request menyatakan panjang potongan pendek (biasanya 0). Server front-end hanya membaca bagian pertama dari request dan meneruskan bagian kedua ke server back-end.

Dalam contoh berikut, teks yang diawali dengan "MALICIOUS REQUEST" diteruskan ke server backend, yang memperlakukan dan memprosesnya sebagai request berikutnya.

POST / HTTP/1.1
Host: website.com
Content-Length: 13
Transfer-Encoding: chunked
 
0
MALICIOUS-REQUEST

Kerentanan TE.CL (Transfer-Encoding.Content-Length)

Serangan Smuggling pada request HTTP TE.CL mengasumsikan bahwa server front-end memprioritaskan kelemahan Transfer-Encoding dan server back-end memprioritaskan kelemahan Content-Length.

Dalam jenis serangan ini, penyerang mendeklarasikan panjang potongan pertama hingga request malicious. Potongan kedua dinyatakan panjangnya nol, sehingga server front-end menganggap request selesai. request diteruskan ke server backend, yang menerima dan memproses request, request terlihat seperti ini:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

15

MALICIOUS-REQUEST
0

Ketika server backend menerima request, Anda dapat melihat bahwa isi request sangat pendek dan panjangnya hanya 3 byte. request dari MALICIOUS-REQUEST dan setelahnya tidak akan diproses. Sebaliknya, pertimbangkan ini sebagai request berikutnya. Ini menyebabkan server terus memproses request berbahaya.

Kerentanan operasi TE-TE (transfer encoding)

Di sini, server front-end dan server back-end dengan benar memprioritaskan header Transfer-Encoding. Namun, penyerang dapat mengaburkan header untuk mengelabui salah satu server.

Ada beberapa cara untuk mengaburkan header. Sebagian besar metode menyertakan header berpasangan atau Transfer-Encoding, salah satunya tidak mengikuti aturan biasa.

Transfer-Encoding: xchunked
Transfer-Encoding: chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding: xchunked

Transfer-Encoding
: chunked
Transfer-Encoding
: chunked

Kode ini hanya sedikit menyimpang dari spesifikasi HTTP, sehingga banyak implementasi server masih menerimanya sebagai sah. Agar serangan berhasil, penyerang harus menemukan variasi header Transfer-Encoding yang diproses oleh satu server dan diabaikan oleh server lainnya.

Dampak dari serangan tersebut tergantung pada apakah server front-end atau server back-end adalah server yang ditipu untuk tidak memproses header Transfer-Encoding. Sisa serangan serupa dengan CL.TE atau TE.CL. Serangan HTTP Request Smuggling tingkat lanjut

Bypass filter keamanan

Jenis serangan ini meneruskan query berbahaya langsung ke server backend sehingga tidak terdeteksi oleh filter keamanan middleware. query kemudian dieksekusi di server backend.

Penggantian respon normal

Jenis serangan ini dapat digunakan ketika middleware adalah server cache. Penyerang mencoba melakukan poisoning cache. Dalam hal ini, respons yang tidak valid disimpan dalam entri cache. Setelah serangan pertama yang berhasil, request penggunaan di masa mendatang mengembalikan query berbahaya dan sekarang di-cache. Hal ini dapat menyebabkan penolakan layanan di server.

Pembajakan kredensial

Dalam jenis serangan ini, penyerang memasukkan bagian dari query ke dalam aliran query dan menunggu query pengguna akhir yang sah. Penyerang mengambil query pengguna dan menggunakan koneksi yang sama untuk menambahkannya ke request parsial. Proxy tidak mengenali bahwa ini adalah dua request yang terpisah dan memperlakukannya sebagai satu.

Ini rumit untuk dicapai, tetapi jika berhasil, penyerang dapat menunggangi sesi pengguna yang valid, seperti cookie dan detail otentikasi HTTP. Anda dapat menggunakan detail koneksi yang valid ini untuk menyelundupkan query berbahaya.

Ini adalah bentuk pembajakan kredensial. Ketika digunakan bersama dengan HTTP Request Smuggling, ini bisa sangat berbahaya karena penyerang dapat menggunakan kredensial pengguna dan tingkat hak istimewa untuk melakukan tindakan POST atas nama pengguna.

Cara mengurangi kerentanan HTTP Request Smuggling

Serangan Smuggling HTTP canggih karena mereka mengeksploitasi ambiguitas dalam interpretasi dan konfigurasi protokol server. Ada beberapa opsi yang dapat dipertimbangkan oleh para profesional TI untuk mengurangi keterpaparan mereka terhadap kerentanan ini.

  • Menginterpretasikan header HTTP secara konsisten di server front-end dan back-end. Jelas ini adalah pilihan terbaik untuk pencegahan. Namun, penyeimbang beban biasanya merupakan peralatan perangkat keras yang mendukung server back-end yang berjalan pada platform terpisah, sehingga tidak selalu menjadi pilihan. Jika Anda tidak dapat menjalankan perangkat lunak yang sama di frontend dan backend, Anda setidaknya harus mengetahui bagaimana setiap server menangani header HTTP dan memastikan bahwa request HTTP ditafsirkan secara konsisten.

  • Menonaktifkan pengoptimalan yang rentan. Jika Anda tidak dapat mengubah konfigurasi backend, nonaktifkan pengoptimalan kinerja menggunakan header Transfer-Encoding atau Content-Length. Ini dapat mengurangi efisiensi lingkungan web, tetapi sangat efektif dalam mencegah serangan ini.

  • Hindari penggunaan penyeimbang beban, jaringan pengiriman konten (CDN), atau proxy terbalik. Jika komponen ini tidak diperlukan dalam pengaturan Anda, mereka biasanya aman dari HTTP Request Smuggling.

  • Gunakan HTTP/2 — Anda dapat mencegah sebagian besar varian serangan ini dengan mengizinkan server front-end dan back-end untuk berkomunikasi hanya menggunakan protokol HTTP/2.

  • Nonaktifkan penggunaan kembali koneksi di server backend. Jika ini memungkinkan secara teknis di lingkungan Anda, Anda dapat sepenuhnya mencegah HTTP Request Smuggling.

  • Konfigurasikan server front-end untuk menormalkan request yang ambigu. Ini mencegah request berbahaya diteruskan ke server backend.

  • Jangan mengekspos log trafict HTTP yang dicatat-log HTTP seharusnya hanya tersedia untuk pengguna administratif sehingga bagian request HTTP yang tidak diinginkan tidak diekspos ke penyerang potensial.

  • Gunakan firewall aplikasi web (WAF). Banyak WAF memiliki teknologi yang mengidentifikasi, memblokir, atau membersihkan lalu lintas HTTP, seperti meminta arahan Smuggling. Organisasi yang saat ini menggunakan WAF harus memeriksa dengan vendor bahwa tingkat perlindungan aktif. Penting juga untuk memeriksa apakah pengaturan WAF perlu diubah untuk melindungi dari kerentanan HTTP Request Smuggling.

Smuggling request HTTP dengan Imperva

Imperva menyediakan firewall aplikasi web yang dapat mencegah serangan HTTP Request Smuggling dan banyak serangan lapisan aplikasi lainnya dengan analisis lalu lintas web ke aplikasi kelas dunia.

Imperva memberikan perlindungan komprehensif untuk aplikasi, API, dan layanan mikro, selain perlindungan Smuggling untuk request HTTP.

Runtime Application Self-Protection (RASP) – Deteksi serangan real-time dan pencegahan dari lingkungan runtime aplikasi Anda dapat dilakukan ke mana pun aplikasi Anda pergi. Hentikan serangan dan suntikan eksternal dan kurangi simpanan kerentanan.

Keamanan API – Perlindungan API otomatis melindungi titik akhir API pada waktu publikasi dan mencegah aplikasi disalahgunakan.

Perlindungan bot tingkat lanjut – Mencegah serangan logika bisnis dari semua titik akses seperti situs web, aplikasi seluler, API, dan lainnya. Dapatkan visibilitas tanpa batas dan kontrol lalu lintas bot untuk menggagalkan penipuan online melalui pembajakan akun dan pengikisan harga yang kompetitif.

Perlindungan DDoS – Memblokir lalu lintas serangan di edge untuk memastikan waktu aktif dan memastikan kelangsungan bisnis tanpa memengaruhi kinerja. Lindungi aset lokal atau berbasis cloud Anda – baik dihosting di AWS, Microsoft Azure, atau cloud publik Google.

Analisis Serangan – Gunakan pembelajaran mesin dan keahlian domain di seluruh tumpukan keamanan aplikasi untuk memastikan visibilitas penuh, mengungkap pola gangguan, mendeteksi serangan aplikasi, dan mengisolasi serta mencegah kampanye serangan.

Perlindungan Sisi Klien – Dapatkan visibilitas dan kontrol kode JavaScript pihak ketiga untuk mengurangi risiko penipuan rantai pasokan dan mencegah pelanggaran data dan serangan sisi klien.

Sekian pembahasan dari saya, selamat mencoba, semoga sukses