Temu Duga Umum: Bagaimanakah Anda Menerangkan dan Mempertahankan Diri daripada Penyeludupan Permintaan HTTP (HTTP Request Smuggling)?

Prompt dan skop

Sebuah aplikasi terletak di belakang CDN, proksi terbalik (reverse proxy), WAF, dan perkhidmatan bahagian belakang. Pasukan keselamatan mendapati bahawa komponen-komponen tidak bersetuju tentang sempadan permintaan dalam aliran bait HTTP/1.1 yang sama, membolehkan bahagian hadapan melihat satu permintaan manakala bahagian belakang menghuraikan permintaan kedua daripada bait-bait yang tertinggal. Terangkan mekanisme tersebut, pengendalian selamat bagi Content-Length dan Transfer-Encoding yang berkonflik, pengesanan, pemulihan, pengesahan, dan pelancaran.

RFC 9112 memberi amaran bahawa peraturan keteguhan (robustness rules) yang berbeza dalam kalangan penerima boleh mewujudkan risiko penyeludupan permintaan. OWASP mengaitkan kelas ini dengan penghuraian yang tidak konsisten antara komponen bahagian hadapan dan bahagian belakang. Soalan ini menguji sama ada anda boleh memudahkan "ketidaksepakatan penghurai" kepada aliran bait, penggunaan semula sambungan, dan sempadan keselamatan dan bukannya sekadar menghafal akronim serangan.

Perkara yang diuji oleh penemu duga

Mengasingkan pembingkaian mesej, penghalaan, dan pengesahan parameter aplikasi.
Menerangkan dengan betul Content-Length, Transfer-Encoding, dan sempadan penurunan taraf (downgrade) HTTP/1.0.
Mengenal pasti proksi mana yang menghurai, sambungan mana yang digunakan semula, dan bagaimana bait yang tertinggal mempengaruhi permintaan seterusnya.
Menggabungkan penolakan permintaan yang samar-samar (ambiguous), satu penghurai yang ketat, dan penutupan sambungan.
Mereka bentuk ujian yang selamat, pemantauan, pelepasan kenari (canary), dan pembalikan tanpa kesan sampingan pengeluaran.
Memeriksa lapisan terjemahan walaupun apabila HTTP/2 atau HTTP/3 digunakan.

Soalan penjelasan

Versi HTTP dan perisian perantara (middleware) mana yang berada dalam laluan? Andaikan proksi HTTP/1.1 dan kolam bahagian belakang.
Adakah bahagian hadapan dan bahagian belakang menggunakan semula sambungan TCP? Penyeludupan biasanya bergantung pada penggunaan semula atau keadaan penghurai yang berbeza.
Adakah jasad berkeping (chunked bodies) dan jasad permintaan dibenarkan? Andaikan pinggir (edge) awam membenarkannya tetapi boleh menolak gabungan yang samar-samar.
Adakah matlamatnya pembendungan segera atau penumpuan penghurai yang kekal? Berikan kedua-duanya.
Bolehkah ujian menggunakan bahagian belakang yang terpencil dan titik akhir tanpa kesan sampingan? Ia mesti berbuat demikian, daripada menghantar trafik yang membinasakan ke persekitaran pengeluaran.

Jawapan tiga puluh saat

Saya akan melukis aliran bait dan penggunaan semula sambungan daripada proksi ke bahagian belakang. Punca utamanya ialah penerima yang berbeza menggunakan peraturan yang berbeza untuk menentukan panjang mesej, terutamanya apabila kedua-dua Content-Length dan Transfer-Encoding atau panjang pendua yang tidak sah muncul. Pinggir menolak kesamaran, menghurai dengan ketat, menutup sambungan atas ralat, dan memastikan pelaksanaan proksi dan bahagian belakang sejajar. Saya akan mengesahkan dengan titik akhir yang terpencil dan perbandingan dua komponen, kemudian memantau ralat 400 yang tidak normal, penetapan semula, ralat penghurai, dan ketidakpadanan bilangan permintaan semasa pelepasan kenari dengan laluan yang boleh diterbalikkan.

Penyelesaian langkah demi langkah

Langkah 1: Lukis sempadan mesej dan sambungan

Senaraikan sama ada klien, CDN, WAF, proksi terbalik, dan bahagian belakang menghuraikan permintaan, menulis semula pengepala, atau menggunakan semula sambungan huluan. HTTP/1.1 ialah protokol aliran bait; setiap penerima memperoleh panjang jasad daripada medan pengepala. Jika dua lapisan tidak bersetuju, bait yang tertinggal boleh menjadi permintaan baharu pada lapisan seterusnya.

Jangan bermula dengan muatan serangan (payload). Gunakan contoh aliran bait yang tidak berbahaya yang menunjukkan bahagian hadapan membaca satu permintaan manakala bahagian belakang membaca dua permintaan, supaya keadaan sempadan adalah jelas.

Langkah 2: Terangkan peraturan panjang dan kesamaran

RFC 9112 mentakrifkan panjang jasad mesej, serta tingkah laku Content-Length dan Transfer-Encoding. Apabila kedua-duanya muncul, penerima tidak boleh memilih salah satu secara bebas dan meneruskannya. Anggap permintaan itu sebagai samar-samar dan tolaknya, biasanya dengan menutup sambungan. Medan Content-Length pendua yang berkonflik juga mesti ditolak dan bukannya mengambil nilai pertama atau terakhir.

Permintaan HTTP/1.0 yang mengandungi Transfer-Encoding tidak boleh dianggap sebagai semantik chunked yang normal. Proseskannya sebagai ralat protokol dan tutup seperti yang diperlukan. Prinsipnya ialah satu peraturan yang ketat untuk setiap penerima, bukannya toleransi "teguh" untuk klien yang tidak dibentuk dengan betul (malformed).

Langkah 3: Terangkan bagaimana penggunaan semula menguatkan impak

Proksi hadapan mungkin membahagikan satu sambungan klien kepada beberapa permintaan huluan sementara kolam bahagian belakang menunggu lebih banyak bait pada sambungan yang digunakan semula. Jika sempadan berbeza, awalan yang disuntik kekal dibimbit (buffered) dan menjadi permulaan permintaan seterusnya. Cekera simpanan (cache), laluan pengesahan, titik akhir pentadbiran dalaman, dan permintaan penyewa lain boleh terjejas.

Oleh itu, pembaikan merangkumi CDN, WAF, proksi, dan terjemahan protokol. Periksa sama ada ralat penghuraian meninggalkan sambungan yang boleh digunakan semula, sama ada penimbal dikosongkan, dan sama ada get laluan (gateway) menjana semula medan panjang yang konsisten apabila menterjemahkan HTTP/2 kepada HTTP/1.1.

Langkah 4: Berikan strategi pembendungan pinggir

Tolak permintaan yang mengandungi kedua-dua Content-Length dan Transfer-Encoding, medan panjang pendua, pembingkaian chunk yang tidak sah, atau versi yang tidak disokong. Tutup sambungan selepas ralat penghuraian dan bukannya menyerahkan bait yang tertinggal kepada permintaan seterusnya. Melumpuhkan penggunaan semula huluan buat sementara waktu pada laluan yang terjejas mungkin membendung risiko, tetapi ia menambah kependaman dan kos sambungan.

Peraturan memerlukan pengecualian yang jelas dan log yang dikategorikan; senarai hitam berasingan dalam setiap komponen mewujudkan satu lagi ketidaksepakatan. Utamakan versi penghurai ketat yang dikongsi dan matriks keserasian untuk klien yang sah.

Langkah 5: Tumpukan penghuraian dan normalkan pengepala

Lengkapkan pembingkaian pada satu sempadan penghuraian dan hantarkan permintaan berstruktur kepada aplikasi. Aplikasi tidak boleh menghuraikan semula pengepala mentah atau mempercayai "panjang yang disahkan" oleh proksi. Jika proksi menulis semula permintaan, alih keluar medan yang samar-samar dan jana satu panjang kanonikal daripada jasad yang dimajukan; bahagian hiliran tidak boleh melihat medan yang lapuk.

HTTP/2 dan HTTP/3 mempunyai lapisan bingkai yang berbeza, tetapi get laluan kepada HTTP/1.1 boleh mencipta semula kesamaran. Audit penggabungan pengepala, penimbalan jasad, pengendalian sambungan ralat, dan laluan penurunan taraf pada setiap titik terjemahan.

Langkah 6: Reka bentuk ujian yang selamat

Dalam persekitaran yang terpencil, letakkan proksi hadapan sebelum bahagian belakang gema (echo backend) yang merekodkan ID permintaan, panjang yang dihuraikan, dan susunan ketibaan. Liputi panjang yang berkonflik, pendua, chunk yang tidak sah, penurunan taraf HTTP/1.0, penggunaan semula sambungan, tamat masa, dan percubaan semula proksi. Sahkan bahawa setiap lapisan melihat bilangan permintaan, kaedah, laluan, dan panjang jasad yang sama.

Jangan sekali-kali menghantar muatan yang mempunyai kesan sampingan akaun, pesanan, atau cache ke persekitaran pengeluaran. Gunakan trafik bayangan (shadow traffic), sambungan sintetik, dan titik akhir baca sahaja; jika laluan sebenar mesti diperiksa, lumpuhkan kesan sampingan dan kekalkan log pada peringkat sambungan.

Langkah 7: Pantau, laksana kenari, dan balikkan

Pantau ralat penghurai, respons 400/431 yang tidak normal, penetapan semula, tamat masa huluan, anomali sempadan pada sambungan yang digunakan semula, dan perbezaan bilangan permintaan antara WAF ke bahagian belakang. Bahagikan mengikut versi proksi, protokol, penyewa, dan laluan supaya satu nod pinggir tidak terlindung oleh nilai purata.

Jalankan penghurai baharu dalam mod bayangan atau pada peratusan kecil terlebih dahulu. Hentikan jika terdapat lonjakan dalam ralat penghurai, kegagalan klien yang sah, atau keletihan sambungan. Balikkan versi laluan dan konfigurasi sambil mengekalkan suis penolakan permintaan samar-samar yang selamat; keserasian tidak boleh menuntut penghuraian yang permisif.

Langkah 8: Kerumitan dan komunikasi

Pembingkaian adalah linear dalam saiz mesej semasa membaca pengepala dan jasad. Pengoptimuman yang penting bukanlah mikrosaat tetapi memastikan setiap bait digunakan oleh satu sempadan penghuraian normatif. Masukkan peraturan RFC, versi komponen, dasar sambungan, dan matriks ujian ke dalam buku panduan operasi (runbook).

Bagi khalayak bukan keselamatan, bandingkannya dengan dua penerima yang mengira helaian dalam sampul surat yang sama secara berbeza, kemudian berikan tindakan yang boleh disahkan: tolak kesamaran, tumpukan penghurai, tutup atas ralat, uji secara terpencil, dan laksanakan pelepasan kenari secara berbalik.

Jawapan model

Penyeludupan permintaan ialah masalah sempadan penghurai, bukannya pepijat laluan aplikasi tunggal. Bahagian hadapan mungkin berhenti pada Content-Length manakala bahagian belakang meneruskan dengan Transfer-Encoding, meninggalkan bait yang dikawal penyerang sebagai permintaan seterusnya pada sambungan yang digunakan semula. Saya akan menginventori setiap penghurai dan titik terjemahan, menyelaraskannya dengan tingkah laku RFC 9112 yang ketat, menolak isyarat panjang yang wujud bersama, pendua, dan chunk yang tidak sah di pinggir, serta menutup sambungan selepas ralat penghuraian.

Saya akan menguji bahagian belakang gema yang terpencil terhadap proksi dengan panjang yang berkonflik, penggunaan semula sambungan, percubaan semula, dan terjemahan protokol, sambil mengesahkan bilangan permintaan, laluan, dan panjang jasad yang serupa. Lancarkan dalam mod bayangan dan pelepasan kenari sambil memantau ralat penghurai, penetapan semula, kegagalan sah, dan ketidakpadanan bilangan. Sebarang pelanggaran akan membalikkan laluan dan versi tetapi mengekalkan penolakan permintaan yang samar-samar.

Kesilapan biasa

Menyebut nama serangan tanpa menerangkan bait dan penggunaan semula sambungan.
Mengatakan "utamakan Content-Length" atau "utamakan Transfer-Encoding" dan bukannya menolak kesamaran.
Mengambil nilai Content-Length pendua yang pertama atau terakhir.
Membaiki aplikasi sahaja dan mengabaikan CDN, WAF, proksi, atau lapisan terjemahan.
Menguji titik akhir yang membinasakan atau gagal mengesahkan bilangan permintaan yang serupa.
Menggunakan semula sambungan selepas kegagalan penghuraian dan membawa bait yang tertinggal ke hadapan.
Menganggap HTTP/2 atau HTTP/3 secara automatik menghapuskan risiko get laluan.
Hanya memerhatikan agregat 5xx semasa pelepasan kenari dan bukannya pecahan mengikut protokol dan klien.

Soalan susulan

Apakah yang patut berlaku apabila kedua-dua Content-Length dan Transfer-Encoding hadir?

Tolak permintaan yang samar-samar di bawah dasar penghuraian yang ketat dan biasanya tutup sambungan. Setiap proksi dan bahagian belakang mesti menggunakan peraturan yang sama; satu lapisan tidak boleh memilih medan yang berbeza dan terus memajukannya.

Patutkah nilai Content-Length pendua yang sama juga ditolak?

Menolak pendua ialah dasar rentas komponen yang paling selamat melainkan keseluruhan rantaian mempunyai satu peraturan penggabungan yang didokumentasikan. Selesaikan keserasian dengan senarai dibenarkan (allowlist) terkawal dan ujian, bukannya tingkah laku komponen yang bebas.

Bagaimanakah anda membuktikan klien normal tidak terjejas?

Inventori versi protokol klien yang sah, pengekodan jasad, dan laluan proksi. Mainkan semula dan sintesiskan mereka secara terpencil, kemudian laksanakan pelepasan kenari sambil memantau ralat 4xx yang sah, penetapan semula, dan kependaman. Balikkan atau naik taraf mengikut jenis klien dan bukannya membuka semula penghuraian yang permisif.

Adakah HTTP/2 kebal sepenuhnya?

Pembingkaian binari menghapuskan sebahagian kesamaran HTTP/1.1, tetapi get laluan HTTP/2-ke-HTTP/1.1 masih mencipta pengepala dan jasad. Audit terjemahan, penggunaan semula, dan penghuraian hiliran dan bukannya bergantung pada protokol klien semata-mata.

Mengapakah sambungan perlu ditutup selepas ralat penghuraian?

Penerima tidak dapat membuktikan sama ada bait yang dibimbit adalah milik permintaan ini atau permintaan seterusnya. Menutup sambungan akan membuang keadaan yang tidak pasti dan menghalang tafsiran semula pada sambungan yang digunakan semula; ukur kos penyambungan semula.

Bagaimanakah anda membezakan penyeludupan permintaan daripada peracunan cache (cache poisoning)?

Penyeludupan ialah percanggahan penghuraian sempadan mesej; peracunan cache menyimpan respons atau kunci yang dikawal penyerang. Penyeludupan boleh membolehkan peracunan, tetapi mula-mula tumpukan pembingkaian dan pengendalian sambungan, kemudian uji kunci cache, penghalaan, dan kebenaran secara berasingan.

Medan audit manakah yang anda simpan?

Rekodkan versi proksi dan bahagian belakang, protokol, ID sambungan, hasil penghuraian, sebab penolakan, ringkasan pengepala yang dinormalkan, ID permintaan, dan status respons. Elakkan jasad yang sensitif; medan tersebut harus mengaitkan keputusan sempadan setiap lapisan dengan pelupusan akhir.