Kehendak soalan dan skop
Proksi anda ingin menghantar data pasca-peningkatan (post-upgrade) sebelum pertukaran protokol HTTP/1.1 disahkan untuk mengurangkan pendam (latency). Terangkan risiko, sempadan keselamatan, dan perubahan yang diperlukan pada klien dan proksi.
Perkara yang dinilai oleh penemu duga
- Mengetahui bahawa peningkatan HTTP/1.1 masih boleh ditolak sebelum pengesahan, jadi kejayaan lalu bukan jaminan.
- Menjelaskan bagaimana bait yang dikawal oleh penyerang boleh ditafsirkan semula sebagai permintaan HTTP pada laluan penolakan.
- Membezakan kekangan Upgrade, CONNECT, WebSocket, dan HTTP/2/3.
- Menyediakan kawalan kejuruteraan seperti menunggu 2xx, menutup sambungan, menyahdayakan penghantaran optimistik, dan sandaran (fallback) yang boleh diperhatikan.
Soalan penjelasan
- Adakah mekanismenya Upgrade atau CONNECT, dan apakah protokol sasaran serta versi HTTP yang terlibat?
- Bolehkah aplikasi yang tidak dipercayai, pengguna, atau origin pihak ketiga mengawal bait seterusnya?
- Adakah sambungan tersebut membawa sijil klien, pengesahan proksi, atau kepercayaan peringkat sambungan yang lain?
- Adakah matlamatnya ialah pendam jabat tangan (handshake latency), atau adakah keserasian HTTP/1.1 dan penggunaan semula sambungan mesti dikekalkan?
Rangka jawapan 30 saat
Saya secara lalai akan melarang data pasca-peningkatan yang tidak dipercayai pada HTTP/1.1 sebelum pengesahan. Klien menunggu respons peningkatan; proksi CONNECT menunggu 2xx atau menghantar Connection: close dan ditutup selepas kegagalan. Sambungan yang ditolak yang mengandungi bait protokol yang tidak diketahui tidak akan digunakan semula. Sahkan HTTP/2/3 secara berasingan untuk semantik strim termultipleksnya, rekod sebab peningkatan dan sandaran, serta uji penyeludupan permintaan (request smuggling) dan percanggahan penghurai (parser disagreement) dalam proksi yang terkawal.
Penyelaman mendalam langkah demi langkah
1. Kenal pasti andaian penghantaran optimistik
HTTP/1.1 boleh menukar protokol dengan Upgrade atau CONNECT, tetapi pelayan mungkin menolak permintaan tersebut. Jika klien menghantar bait protokol baharu sebelum melihat status, dua penghurai berkemungkinan berlaku: protokol baharu jika diterima, HTTP/1.1 jika ditolak. Peningkatan yang berjaya sebelum ini tidak membuktikan peningkatan seterusnya akan diterima.
2. Terangkan laluan penyeludupan permintaan
Apabila data seterusnya dikawal oleh sumber yang tidak dipercayai, laluan penolakan boleh mentafsir bait tersebut sebagai permintaan HTTP tambahan. Jika pengesahan peringkat sambungan telah pun berjaya, proksi mungkin menganggap permintaan yang direka oleh penyerang sebagai trafik klien yang disahkan. Percanggahan antara sempadan penghuraian proksi dan klien juga boleh mendedahkan kerentanan penghurai.
3. Pilih pelaksanaan yang selamat
Pendekatan paling selamat adalah menunggu pengesahan sebelum menghantar data seterusnya. RFC 9931 memerlukan klien proksi HTTP/1.1 CONNECT menunggu 2xx atau menghantar Connection: close; proksi harus menutup sambungan asas apabila menolak CONNECT yang tidak selamat. Jika pendam adalah penting, utamakan HTTP/2 atau lebih baharu dengan semantik strim yang jelas dan sahkan peraturan jabat tangan protokol sasaran itu sendiri.
4. Bina sandaran, pemantauan, dan ujian
Sekiranya peningkatan gagal, tandakan sambungan sebagai tidak boleh digunakan semula dan cipta permintaan HTTP/1.1 yang baharu; jangan sekali-kali menganggap bait tidak diketahui yang telah dihantar sebagai data permintaan yang boleh dicuba semula. Ukur penerimaan, sebab penolakan, penutupan sambungan, dan percubaan semula tanpa mencatat kelayakan atau badan permintaan ke dalam log. Uji muatan yang tidak dipercayai, proksi yang disahkan, 401/407, pengalihan (redirects), tamat masa, percanggahan penghurai, dan sandaran HTTP/2/3.
Contoh jawapan berkualiti tinggi
Saya tidak akan menganggap penghantaran optimistik sebagai pengoptimuman umum. HTTP/1.1 Upgrade atau CONNECT boleh ditolak sebelum pengesahan; bait seterusnya yang dikawal penyerang kemudiannya boleh dihuraikan sebagai permintaan tambahan, mewujudkan penyeludupan permintaan (request smuggling), dan pengesahan peringkat sambungan meningkatkan impak tersebut. Saya secara lalai akan menunggu pengesahan. Proksi CONNECT menunggu 2xx atau menggunakan Connection: close dan ditutup selepas penolakan; kegagalan Upgrade tidak digunakan semula. Untuk pendam yang lebih rendah, nilaikan semantik strim HTTP/2/3. Sahkan dengan muatan yang tidak dipercayai, proksi yang disahkan, status ralat, pengalihan, dan percubaan semula; pantau penerimaan dan sebab penutupan; pastikan sandaran tidak sekali-kali membocorkan permintaan atau kelayakan.
Kesilapan lazim
- Menghantar bait seterusnya yang sewenang-wenangnya hanya kerana peningkatan baru-baru ini berjaya.
- Mengesahkan pelayan sahaja dan mengabaikan sempadan penghuraian klien, proksi, dan pihak ketiga.
- Menggunakan semula sambungan CONNECT yang ditolak atau memajukan data muatan yang dibimbit (buffered).
- Menggunakan peraturan jabat tangan WebSocket untuk setiap token Upgrade.
- Menanda aras hanya HTTP/1.1 tanpa membezakan semantik strim HTTP/2/3.
- Mencuba semula dengan sambungan yang mengandungi bait tidak diketahui atau menulis badan permintaan ke log diagnostik.
Soalan susulan dan jawapan
Mengapakah Connection: close mengurangkan risiko?
Ia menutup sambungan selepas mengendalikan permintaan, jadi peningkatan yang ditolak tidak meneruskan penghuraian bait seterusnya yang mungkin bercampur pada sambungan tersebut. Ia mengorbankan penggunaan semula dan harus dipertimbangkan berbanding menunggu 2xx.
Bolehkah WebSocket menghantar secara optimistik?
Jabat tangan WebSocket memerlukan klien menunggu respons pelayan sebelum menghantar data seterusnya. Peraturan untuk satu protokol tidak boleh digeneralisasikan kepada setiap token Upgrade.
Bagaimanakah anda mengimbangi pendam dan keselamatan?
Ukur kos sebenar menunggu, kemudian utamakan HTTP/2 atau HTTP/3. Jika HTTP/1.1 diperlukan, tunggu pengesahan dan tutup sambungan semasa sandaran (fallback). Tiada pengoptimuman yang boleh membenarkan data yang tidak dipercayai melintasi sempadan penghuraian yang belum disahkan.