Perintah dan cakupan
Proksi Anda ingin mengirim data pasca-upgrade sebelum peralihan protokol HTTP/1.1 dikonfirmasi untuk mengurangi latensi. Jelaskan risiko, batasan aman, dan perubahan yang diperlukan pada klien dan proksi.
Hal yang dievaluasi pewawancara
- Mengetahui bahwa upgrade HTTP/1.1 masih dapat ditolak sebelum konfirmasi, sehingga keberhasilan sebelumnya bukanlah jaminan.
- Menjelaskan bagaimana byte yang dikendalikan penyerang dapat diinterpretasikan ulang sebagai permintaan HTTP pada jalur penolakan.
- Membedakan batasan Upgrade, CONNECT, WebSocket, dan HTTP/2/3.
- Menyediakan kontrol rekayasa seperti menunggu 2xx, menutup koneksi, menonaktifkan pengiriman optimistik, dan fallback yang dapat diobservasi.
Pertanyaan klarifikasi
- Apakah mekanismenya berupa Upgrade atau CONNECT, dan protokol target serta versi HTTP apa yang terlibat?
- Bisakah aplikasi, pengguna, atau origin pihak ketiga yang tidak tepercaya mengendalikan byte berikutnya?
- Apakah koneksi membawa sertifikat klien, autentikasi proksi, atau kepercayaan tingkat koneksi lainnya?
- Apakah tujuannya adalah latensi handshake, atau kompatibilitas HTTP/1.1 dan penggunaan kembali koneksi (connection reuse) harus dipertahankan?
Kerangka jawaban 30 detik
Secara default, saya akan melarang data pasca-upgrade yang tidak tepercaya pada HTTP/1.1 sebelum konfirmasi. Klien menunggu respons upgrade; proksi CONNECT menunggu 2xx atau mengirim Connection: close dan menutup setelah kegagalan. Koneksi yang ditolak yang berisi byte protokol yang tidak dikenal tidak digunakan kembali. Validasi HTTP/2/3 secara terpisah untuk semantik stream termultipleks mereka, catat alasan upgrade dan fallback, serta uji request smuggling dan ketidaksesuaian parser (parser disagreement) dalam proksi yang terkontrol.
Pembahasan mendalam langkah demi langkah
1. Mengidentifikasi asumsi pengiriman optimistik
HTTP/1.1 dapat beralih protokol dengan Upgrade atau CONNECT, tetapi server dapat menolak permintaan tersebut. Jika klien mengirim byte protokol baru sebelum melihat statusnya, ada dua parser yang memungkinkan: protokol baru jika diterima, HTTP/1.1 jika ditolak. Upgrade sebelumnya yang berhasil tidak membuktikan bahwa upgrade berikutnya akan diterima.
2. Menjelaskan jalur request smuggling
Ketika data berikutnya dikendalikan oleh sumber yang tidak tepercaya, jalur penolakan dapat menginterpretasikan byte tersebut sebagai permintaan HTTP tambahan. Jika autentikasi tingkat koneksi telah berhasil, proksi dapat memperlakukan permintaan yang dibuat oleh penyerang sebagai lalu lintas klien yang terautentikasi. Ketidaksesuaian antara batasan parsing proksi dan klien juga dapat mengekspos kerentanan parser.
3. Memilih implementasi yang aman
Pendekatan paling aman adalah menunggu konfirmasi sebelum mengirim data berikutnya. RFC 9931 mewajibkan klien proksi HTTP/1.1 CONNECT untuk menunggu 2xx atau mengirim Connection: close; proksi harus menutup koneksi yang mendasarinya saat menolak CONNECT yang tidak aman. Jika latensi sangat penting, prioritaskan HTTP/2 atau versi lebih baru dengan semantik stream eksplisit dan validasi aturan handshake dari protokol target itu sendiri.
4. Membangun fallback, pemantauan, dan pengujian
Pada kegagalan upgrade, tandai koneksi sebagai tidak dapat digunakan kembali dan buat permintaan HTTP/1.1 baru; jangan pernah memperlakukan byte tak dikenal yang sudah terkirim sebagai data permintaan yang dapat dicoba lagi (retryable). Ukur penerimaan, alasan penolakan, penutupan, dan percobaan ulang tanpa mencatat kredensial atau body ke log. Uji payload yang tidak tepercaya, proksi terautentikasi, 401/407, pengalihan (redirect), waktu habis (timeout), ketidaksesuaian parser, dan fallback HTTP/2/3.
Contoh jawaban berkualitas tinggi
Saya tidak akan memperlakukan pengiriman optimistik sebagai optimasi umum. HTTP/1.1 Upgrade atau CONNECT dapat ditolak sebelum konfirmasi; byte berikutnya yang dikendalikan penyerang kemudian dapat diparsing sebagai permintaan tambahan, sehingga memicu request smuggling, dan autentikasi tingkat koneksi memperbesar dampaknya. Secara default, saya akan menunggu konfirmasi. Proksi CONNECT menunggu 2xx atau menggunakan Connection: close dan menutup setelah penolakan; kegagalan Upgrade tidak digunakan kembali. Untuk latensi yang lebih rendah, evaluasi semantik stream HTTP/2/3. Validasi dengan payload yang tidak tepercaya, proksi terautentikasi, status error, pengalihan, dan percobaan ulang; pantau alasan penerimaan dan penutupan; pastikan fallback tidak pernah membocorkan permintaan atau kredensial.
Kesalahan umum
- Mengirim byte berikutnya yang arbitrer hanya karena upgrade baru-baru ini berhasil.
- Hanya memvalidasi server dan mengabaikan batasan parsing klien, proksi, dan pihak ketiga.
- Menggunakan kembali koneksi CONNECT yang ditolak atau meneruskan data payload yang di-buffer.
- Menerapkan aturan handshake WebSocket ke setiap token Upgrade.
- Hanya melakukan benchmark pada HTTP/1.1 tanpa membedakan semantik stream HTTP/2/3.
- Mencoba ulang dengan koneksi yang berisi byte tak dikenal atau menulis body ke log diagnostik.
Pertanyaan lanjutan dan jawabannya
Mengapa Connection: close mengurangi risiko?
Ini menutup koneksi setelah menangani permintaan, sehingga upgrade yang ditolak tidak melanjutkan parsing byte berikutnya yang mungkin bercampur pada koneksi tersebut. Ini mengorbankan penggunaan kembali koneksi dan harus dipertimbangkan terhadap opsi menunggu 2xx.
Bisakah WebSocket mengirim secara optimistik?
Handshake WebSocket mengharuskan klien untuk menunggu respons server sebelum mengirim data berikutnya. Aturan untuk satu protokol tidak boleh digeneralisasi ke setiap token Upgrade.
Bagaimana Anda menyeimbangkan latensi dan keamanan?
Ukur biaya sebenarnya dari menunggu, lalu prioritaskan HTTP/2 atau HTTP/3. Jika HTTP/1.1 diperlukan, tunggu konfirmasi dan tutup koneksi pada fallback. Tidak ada optimasi yang boleh membiarkan data yang tidak tepercaya melintasi batasan parsing yang belum dikonfirmasi.