Temu Duga Backend: Mengapakah API HTTP Yang Diautentikasi Perlu Mengelak Daripada Mengalihkan ke HTTPS?

Maklum balas dan skop

API anda yang diautentikasi mendengar pada kedua-dua HTTP dan HTTPS, dan permintaan HTTP menerima 301 ke HTTPS. Terangkan risiko, perubahan pelayan dan klien, serta pelan migrasi untuk klien legasi. Gesaan ini berlandaskan Draf Internet Mei 2026 kumpulan kerja HTTPAPI; ia masih dalam proses dan bukan RFC muktamad.

Perkara yang diuji oleh penemu duga

• Menyedari bahawa kelayakan telah merentasi rangkaian teks biasa sebelum pengalihan berlaku.
• Menggabungkan HSTS, rekod DNS HTTPS, penyekatan sambungan, dan kuki Secure.
• Mengendalikan hos kongsi, klien legasi, proksi, dan pembatalan kelayakan.
• Membuktikan pengurangan risiko dengan isyarat yang boleh diukur berbanding hanya menyebut "gunakan HTTPS."

Soalan untuk dijelaskan sebelum menjawab

1. Adakah HTTP dan HTTPS menggunakan nama hos dan pendengar (listener) yang sama?
2. Adakah kelayakan merupakan token Bearer, kuki, kunci API, atau tandatangan permintaan?
3. Adakah terdapat klien legasi, proksi perusahaan, atau pemanggil dalaman yang tidak boleh dinaik taraf serta-merta?
4. Adakah titik masuk HTTP juga menyediakan sumber yang tidak diautentikasi?
5. Adakah anda sudah menggunakan HSTS, rekod DNS HTTPS, putaran kunci, dan log audit?

Rangka kerja jawapan 30 saat

Pengalihan tidak boleh memulihkan kelayakan yang telah dihantar dalam teks biasa; pemerhati pasif boleh menyalin token Bearer atau kuki. Utamakan untuk menggagalkan kemasukan HTTP sebelum sambungan diautentikasi dibuat, gunakan rekod DNS HTTPS dan HSTS untuk mengurangkan salah konfigurasi penggunaan kali pertama dan berulang, tetapkan Secure pada kuki, dan pastikan klien menolak URL tidak selamat secara lalai. Jika penyekatan serta-merta adalah mustahil, kembalikan 403 yang sama untuk setiap permintaan teks biasa yang mengandungi kelayakan dan batalkan kelayakan yang mungkin telah bocor. Lakukan migrasi dengan metrik, tempoh peralihan, dan keupayaan pengunduran (rollback).

Perbincangan mendalam langkah demi langkah

1. Terangkan bila kebocoran berlaku

Klien menghantar permintaan HTTP terlebih dahulu, yang berpotensi mengandungi Authorization, kuki, atau kunci API. Respons 301 yang menyusul tidak dapat memadamkan apa yang telah merentasi rangkaian. Penyerang boleh memainkan semula (replay) token Bearer atau kuki. Percubaan semula HTTPS yang berjaya juga boleh menyembunyikan salah konfigurasi klien untuk jangka masa yang panjang.

2. Reka bentuk titik masuk pelayan

Untuk titik akhir yang diautentikasi, lumpuhkan pendengaran teks biasa awam terlebih dahulu atau hadkan port 80 kepada rangkaian yang dipercayai secara eksplisit. Jangan anggap 301 sebagai kawalan keselamatan. Jika hos kongsi mesti mengekalkan HTTP, get laluan (gateway) harus mengenali permintaan yang mengandungi kelayakan dan mengembalikan 403 yang sama tanpa mendedahkan sama ada kelayakan itu sah atau tidak.

HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0

Respons tidak boleh berbeza untuk kelayakan sah dan tidak sah, atau penyerang akan mendapat oracle ujian bagi nilai yang dicuri.

3. Kurangkan kesilapan klien penggunaan kali pertama

Rekod DNS HTTPS boleh memberitahu klien untuk menggunakan sambungan selamat semasa persediaan sambungan. HSTS menaik taraf sambungan kemudian selepas lawatan HTTPS yang berjaya. Kedua-duanya tidak sempurna: HSTS bergantung pada sambungan terdahulu tersebut dan ketahanan klien, manakala rekod DNS boleh disekat. SDK, CLI, dan pengesahan konfigurasi harus menolak http secara lalai dan menyediakan mesej pemulihan yang boleh diambil tindakan.

4. Hadkan penggunaan kelayakan

Kuki harus membawa atribut Secure. Token harus dihadkan kepada konteks selamat, dengan tandatangan terikat permintaan atau sambungan jika sesuai. Pembatalan berbeza mengikut jenis kelayakan: kunci API yang boleh dimainkan semula, token Bearer, dan kuki secara amnya memerlukan pembatalan serta-merta, manakala tandatangan terbitan yang tidak boleh dipalsukan mungkin tidak memerlukannya.

5. Kendalikan kelayakan yang terdedah

Anggap sebarang kelayakan yang diterima melalui teks biasa sebagai berpotensi dikompromi. Pelayan boleh mengembalikan 403 yang seragam terlebih dahulu, kemudian menerangkan "kelayakan dibatalkan" pada penggunaan selamat yang seterusnya. Rekodkan pembatalan dalam log audit, maklumkan pemilik untuk memutarkannya, dan jangan sekali-kali meletakkan nilai sensitif dalam log, cache, atau badan ralat.

6. Lakukan migrasi dengan selamat

Tolak HTTP terlebih dahulu dalam SDK dan persekitaran ujian, kemudian lumpuhkan titik masuk teks biasa untuk penyewa (tenant) baharu, dan akhirnya migrasikan penyewa legasi secara kelompok. Berikan klien yang memerlukan proksi lama titik akhir peralihan singkat yang tidak pernah menerima kelayakan. Tetapkan tarikh akhir, pantau kadar 403 dan penyelesaian putaran, dan alihkan API yang diautentikasi ke nama hos atau dasar get laluan yang berasingan apabila sumber awam masih memerlukan HTTP.

7. Sahkan kawalan

Gunakan tangkapan paket (packet capture) untuk mengesahkan bahawa Authorization, kuki, dan kunci API tidak pernah muncul dalam teks biasa. Sahkan kegagalan sambungan dan kelakuan 403, kemudian uji caching HSTS, lawatan kali pertama, proksi, percubaan semula, dan pengunduran. Jejak permintaan teks biasa, permintaan teks biasa yang mengandungi kelayakan, pembatalan automatik, positif palsu 403, bahagian klien legasi, dan penyelesaian migrasi.

Contoh jawapan berkualiti tinggi

Saya tidak akan menganggap 301 sebagai penyelesaian keselamatan untuk API yang diautentikasi, kerana kelayakan telah merentasi rangkaian teks biasa sebelum pengalihan berlaku. Pemerhati pasif boleh menyalin token Bearer atau kuki, dan percubaan semula HTTPS yang berjaya boleh menyembunyikan kesilapan klien.

Pelayan harus terlebih dahulu melumpuhkan HTTP awam pada titik akhir yang diautentikasi. Jika hos kongsi tidak boleh berbuat demikian serta-merta, get laluan mengembalikan 403 yang sama untuk setiap permintaan HTTP yang mengandungi kelayakan, tidak mendedahkan kesahihan kelayakan, dan menandakan kelayakan itu sebagai berpotensi terdedah. Token yang boleh dimainkan semula, kunci API, dan kuki dibatalkan serta diputarkan. SDK, CLI, dan semakan konfigurasi menolak http secara lalai; rekod DNS HTTPS dan HSTS mengurangkan kesilapan kali pertama dan berulang, serta kuki membawa Secure.

Lakukan migrasi secara berperingkat merentasi persekitaran ujian, penyewa baharu, dan penyewa legasi. Berikan proksi perusahaan laluan peralihan singkat yang tidak menerima sebarang kelayakan. Sahkan dengan tangkapan paket dan ukur permintaan teks biasa, permintaan teks biasa yang mengandungi kelayakan, penyelesaian pembatalan dan putaran, positif palsu 403, dan bahagian klien legasi. Dokumen IETF masih merupakan draf, jadi komitmen pelaksanaan kekal boleh dilaraskan.

Kesilapan lazim

• Menganggap bahawa pengalihan HTTPS melindungi pengepala Authorization atau kuki yang telah dihantar.
• Mengkonfigurasi HSTS sahaja sambil mengabaikan penggunaan kali pertama, klien legasi, dan SDK bukan penyemak imbas.
• Mengembalikan respons teks biasa yang berbeza untuk kelayakan sah dan tidak sah.
• Menganggap setiap kelayakan adalah sama dan mengabaikan perbezaan tandatangan terbitan berbanding token yang boleh dimainkan semula.
• Menyingkirkan HTTP tanpa pelan migrasi, pemantauan, pembatalan, atau pengunduran.

Soalan susulan dan jawapan

Bagaimana jika titik masuk HTTP masih menyediakan sumber awam?

Alihkan API yang diautentikasi ke nama hos yang berasingan, atau asingkan laluan dan pengepala kelayakan di get laluan. Sumber awam boleh mempunyai dasar pengalihan tersendiri; titik akhir yang diautentikasi mesti menolak permintaan teks biasa yang mengandungi kelayakan.

Adakah HSTS menyelesaikan lawatan kali pertama?

Tidak sepenuhnya. HSTS memerlukan sambungan HTTPS terdahulu yang berjaya dan ketahanan klien. SDK, semakan konfigurasi, rekod DNS HTTPS, dan semakan pelaksanaan mestilah meliputi sambungan kali pertama juga.

Bilakah kelayakan perlu dibatalkan?

Anggap kelayakan yang dilihat dalam teks biasa sebagai berpotensi terdedah. Batalkan dan putarkan token yang boleh dimainkan semula, kunci API, dan kuki. Untuk tandatangan terbitan yang tidak boleh dipalsukan, tentukan daripada model ancaman sama ada pembatalan adalah perlu.

Bagaimanakah anda mengelakkan migrasi yang mengganggu?

Dayakan penolakan dalam ujian dan penyewa baharu terlebih dahulu, perhatikan klien legasi dan positif palsu 403, kemudian migrasikan secara berkelompok. Kekalkan titik akhir peralihan singkat yang tidak menerima kelayakan dan alih keluarnya selepas tarikh akhir yang jelas.