Perbedaan Framing HTTP/1.1 Membentuk Batas Request Smuggling

Satu koneksi HTTP/1.1 dapat membawa beberapa request secara berurutan. Setiap recipient karena itu harus menentukan secara tepat posisi akhir satu request sebelum mem-parsing request berikutnya. Pada koneksi langsung dari client ke origin, satu parser mengambil keputusan tersebut. Dalam deployment dengan reverse proxy, gateway, load balancer, cache, atau intermediary lain, byte stream yang sama dapat melewati beberapa parser sebelum mencapai kode aplikasi.

Request smuggling dapat terjadi ketika recipient yang berdekatan menetapkan batas berbeda terhadap byte yang sama. Masalahnya bukan sekadar header malformed yang mencapai aplikasi. Masalah tersebut merupakan perbedaan antara state machine protokol: satu recipient menganggap request telah selesai sementara recipient lain masih memperlakukan sebagian byte sebagai body, atau sebaliknya. Byte yang tersisa pada persistent connection kemudian dapat ditafsirkan dalam konteks request yang berbeda.

Message framing adalah state koneksi

RFC 9112 mendefinisikan framing message HTTP/1.1 dan urutan aturan untuk menentukan panjang message body. Untuk request, Content-Length dan Transfer-Encoding merupakan sinyal framing. Interpretasinya menentukan jumlah byte yang termasuk dalam message saat ini.

Sifat tersebut membuat framing berbeda dari metadata aplikasi biasa. Field seperti User-Agent sering dapat diabaikan tanpa mengubah posisi awal request berikutnya. Framing field tidak dapat diperlakukan sembarangan karena perbedaan parsing dapat menggeser batas message pada koneksi.

Pertimbangkan byte stream secara skematis:

header request A
byte body request A
header request B

Jika intermediary menetapkan jumlah byte body request A lebih sedikit daripada origin, kedua komponen tidak lagi sepakat mengenai posisi awal request B. Penggunaan ulang persistent connection membuat perbedaan itu berdampak melampaui satu request malformed.

RFC 9112 secara eksplisit menyebut perbedaan parsing protokol antar-recipient sebagai dasar request smuggling. Properti keamanan yang relevan dengan demikian adalah kesepakatan parser di seluruh rantai, bukan sekadar kemampuan setiap komponen mem-parsing HTTP valid secara terpisah.

Transfer-Encoding dan Content-Length memiliki precedence yang ditetapkan

HTTP/1.1 memiliki aturan untuk request yang membawa Transfer-Encoding sekaligus Content-Length. RFC 9112 menetapkan bahwa Transfer-Encoding mengesampingkan Content-Length. Spesifikasi tersebut juga menyatakan message seperti itu dapat menandakan request smuggling atau response splitting dan semestinya diperlakukan sebagai error. Intermediary yang tetap meneruskan message harus menghapus Content-Length yang diterima sebelum meneruskannya setelah transfer coding diproses.

Spesifikasi yang sama melarang sender mengirim Content-Length dalam message yang memiliki Transfer-Encoding. Server dapat menolak request yang berisi kedua field atau memprosesnya berdasarkan Transfer-Encoding, dan server harus menutup koneksi setelah memberikan respons terhadap request tersebut.

Persyaratan ini mempersempit ambiguitas pada implementasi yang patuh. Namun, persyaratan tersebut tidak otomatis membuat deployment heterogen menjadi konsisten. Keamanan tetap bergantung pada setiap parser yang melihat request untuk menerapkan aturan kompatibel terhadap sintaks field, field duplikat, transfer coding, whitespace, terminasi baris, dan normalisasi yang dilakukan sebelum forwarding.

Front end yang menormalisasi request menjadi representasi tanpa ambiguitas sebelum reuse atau forwarding dapat mengurangi jumlah interpretasi yang tersedia bagi downstream. Sebaliknya, front end yang menerima sintaks lebih longgar daripada hop berikutnya dapat mempertahankan perbedaan parser.

Parsing longgar dapat memperbesar perbedaan

RFC 9112 mengizinkan fleksibilitas tertentu pada whitespace di request-line, tetapi juga memperingatkan bahwa parsing longgar dapat menciptakan kerentanan request smuggling ketika beberapa recipient menafsirkan robustness secara berbeda. Persoalan arsitektural yang sama berlaku lebih luas: toleransi aman hanya jika tidak menciptakan makna kedua pada batas forwarding.

Ini merupakan jebakan umum pada protocol stack. Parser dapat menerima sintaks yang tidak biasa demi kompatibilitas dan tetap tampak benar dalam pengujian lokal. Kegagalan keamanan baru muncul ketika komponen lain menerima representasi yang sudah diubah atau dikonsumsi sebagian lalu menerapkan grammar berbeda.

Batas header membentuk boundary terkait. RFC 9110 mewajibkan server yang menerima request field lebih besar daripada yang bersedia diproses untuk mengembalikan respons 4xx yang sesuai. Mengabaikan field secara diam-diam dapat meningkatkan paparan request smuggling karena downstream recipient mungkin masih memproses field yang dibuang oleh komponen upstream.

Perbandingan yang relevan bukan sekadar parser ketat melawan parser toleran. Pertanyaannya adalah apakah setiap hop mencapai keputusan framing yang sama atau menghentikan rantai request secara aman ketika keputusan tersebut tidak dapat dicapai.

Translasi protokol tidak menghapus risiko framing

HTTP/2 dan HTTP/3 tidak membatasi request dengan mekanisme level koneksi Content-Length versus chunked transfer yang sama seperti HTTP/1.1. HTTP/2 membawa content request dalam frame pada stream, sedangkan HTTP/3 membawa setiap request pada QUIC request stream tersendiri. Hal tersebut menghapus sebagian ambiguitas framing HTTP/1.1 pada leg protokol tersebut.

Deployment tetap dapat menerjemahkan antarversi protokol. Gateway dapat menerima HTTP/2 lalu mengirim HTTP/1.1 ke origin, atau menerima HTTP/1.1 lalu menghasilkan representasi lain untuk downstream. Titik translasi bertanggung jawab membentuk message yang valid dan tidak ambigu bagi protokol berikutnya.

RFC 9113 menganggap message HTTP/2 malformed ketika nilai content-length tidak sama dengan total panjang payload DATA frame untuk message yang membawa content. Aturan tersebut memberi recipient HTTP/2 pemeriksaan konsistensi yang konkret. Jika translator kemudian menghasilkan HTTP/1.1, translator tetap harus membentuk framing yang memenuhi aturan HTTP/1.1.

Analisis keamanan karena itu mengikuti setiap leg protokol dan setiap konversi, bukan menetapkan satu versi protokol untuk deployment secara keseluruhan.

Penolakan lebih kuat daripada perbaikan ambigu

Ketika recipient menemukan framing yang dapat mendukung interpretasi bertentangan, menolak request dan menutup koneksi HTTP/1.1 terkait menghapus byte residual dari parsing request berikutnya. Tindakan ini berbeda secara material dari menebak maksud sender lalu mempertahankan koneksi agar dapat digunakan ulang.

Normalisasi dapat aman ketika recipient telah mem-parsing satu interpretasi valid lalu menghasilkan representasi baru sesuai aturan hop berikutnya. Meneruskan framing field ambigu dalam bentuk asli tanpa parsing yang tegas mempertahankan kondisi yang memungkinkan perbedaan.

Kontrol operasional perlu mencerminkan perbedaan ini. Logging request malformed berguna untuk diagnosis, tetapi tidak mengembalikan sinkronisasi parser. Penanganan koneksi, perilaku forwarding, dan normalisasi menentukan apakah byte ambigu dapat memengaruhi request berikutnya.

Konsistensi parser adalah properti deployment end-to-end

Satu jalur request dapat berisi software dari vendor berbeda, versi protokol berbeda, lapisan konfigurasi berbeda, dan siklus rilis berbeda. Menguji hanya proxy publik atau hanya origin melewatkan relasi terpenting: apakah komponen yang berdekatan menetapkan batas yang sama terhadap traffic yang diterima.

Validasi yang berguna menargetkan jalur gabungan. Kasus dengan sinyal framing yang bertentangan, length field duplikat, transfer coding yang tidak didukung, whitespace tidak biasa, field berukuran terlalu besar, dan translasi protokol harus menghasilkan satu interpretasi konsisten atau penolakan aman sebelum byte masuk ke konteks request lain.

Hal tersebut tidak mengharuskan setiap komponen mengekspos internal parser yang identik. Interface di antaranya harus mempertahankan satu batas message.

Batas keamanan utama pada request smuggling HTTP/1.1 dengan demikian berada pada handoff antar-parser. Standar menetapkan aturan framing, tetapi keamanan deployment bergantung pada aturan tersebut tetap konsisten melewati setiap intermediary, tahap normalisasi, dan konversi protokol tanpa menciptakan interpretasi kedua.

Referensi

Keamanan Siber HTTP Request Smuggling Keamanan Protokol