Apa header HTTP "Upgrade-Insecure-Requests"?


221

Saya membuat permintaan POST ke situs HTTP (non-HTTPS), memeriksa permintaan di Alat Pengembang Chrome, dan menemukan bahwa itu menambahkan header sendiri sebelum mengirimnya ke server:

Upgrade-Insecure-Requests: 1

Setelah melakukan pencarian Upgrade-Insecure-Requests, saya hanya dapat menemukan informasi tentang server yang mengirim header ini :

Content-Security-Policy: upgrade-insecure-requests

Ini tampaknya terkait, tetapi masih sangat berbeda karena dalam kasus saya, KLIEN mengirimkan tajuk di Permintaan , sedangkan semua informasi yang saya temukan mengenai SERVER yang mengirim tajuk terkait dalam Respons .


Jadi mengapa Chrome (44.0.2403.130 m) ditambahkan Upgrade-Insecure-Requestske permintaan saya dan apa fungsinya?


Pembaruan 2016-08-24:

Header ini telah ditambahkan sebagai Rekomendasi Kandidat W3C dan sekarang diakui secara resmi.

Bagi mereka yang baru saja menemukan pertanyaan ini dan bingung, jawaban yang bagus dari Simon East menjelaskannya dengan baik.

The Upgrade-Insecure-Requests: 1sundulan dulu HTTPS: 1 di sebelumnya Draft W3C Kerja dan diganti namanya diam-diam oleh Chrome sebelum perubahan menjadi diterima secara resmi.

(Pertanyaan ini ditanyakan selama transisi ini ketika tidak ada dokumentasi resmi tentang tajuk ini dan Chrome adalah satu-satunya browser yang mengirim tajuk ini.)


1
Firefox juga melakukannya.
dakab

Harus baru; Saya melakukan pengembangan pada Firefox terlebih dahulu dan tajuk ini jelas tidak dikirim dari Firefox tahun lalu.
user193130

Jawaban:


274

Jawaban singkat: ini terkait erat dengan Content-Security-Policy: upgrade-insecure-requeststajuk respons, yang menunjukkan bahwa browser mendukungnya (dan sebenarnya lebih suka).

Butuh waktu 30 menit bagi saya untuk Googling, tetapi akhirnya saya menemukannya terkubur dalam spesifikasi W3.

Kebingungan muncul karena tajuk dalam spesifikasi itu HTTPS: 1, dan ini adalah bagaimana Chromium menerapkannya, tetapi setelah ini memecah banyak situs web yang memiliki kode buruk (terutama WordPress dan WooCommerce), tim Chromium meminta maaf:

"Aku minta maaf atas kerusakannya; aku tampaknya meremehkan dampaknya berdasarkan umpan balik selama dev dan beta."
- Mike West, dalam Masalah Chrome 501842

Perbaikan mereka adalah untuk mengubah nama menjadi Upgrade-Insecure-Requests: 1, dan spesifikasi sejak itu telah diperbarui agar sesuai.

Bagaimanapun, berikut adalah penjelasan dari spesifikasi W3 (seperti yang muncul pada saat itu) ...

The HTTPSkolom header permintaan HTTP mengirimkan sinyal ke server mengekspresikan preferensi klien untuk respon dienkripsi dan dikonfirmasi, dan bahwa hal itu dapat berhasil menangani upgrade-aman-permintaan direktif untuk membuat preferensi mulus mungkin untuk memberikan.

...

Ketika server menemukan preferensi ini dalam tajuk permintaan HTTP, itu HARUS mengarahkan pengguna ke representasi yang berpotensi aman dari sumber daya yang diminta.

Ketika server menemukan preferensi ini dalam header permintaan HTTPS, itu HARUS menyertakan Strict-Transport-Securityheader dalam respons jika host permintaan aman-HSTS atau aman-kondisional HSTS [RFC6797].


1
Saya gagal memahaminya. Saya a.comdan mengarahkan Anda ke b.com, sambil memberikan tajuk ini ke b.comdan mengirim beberapa informasi. Jika Anda tidak berada di bawah saluran aman b.com, serangan sniffing sudah dapat terjadi, karena saya telah mengirim data ke b.comsamping permintaan saya. Bisakah Anda memandu kami ke skenario sederhana tentang cara membuat koneksi lebih aman bagi pengguna?
Saeed Neamati

@ SaeedNeamati Di bawah perspektif yang sangat ketat, itu tidak membuat apa pun lebih aman. Jika Anda memiliki persyaratan keamanan normal maka Anda harus memastikan Anda terhubung melalui HTTPS terlebih dahulu dan tidak bergantung pada ini. Yang sedang berkata, saya akan menggambarkan ini dalam konteks gagasan " Percaya pada Penggunaan Pertama ", yang memang membantu secara pasif.
mentega

1
Saya melihat ini lebih sebagai keinginan klien daripada alat keamanan. Ini seperti tajuk "DNT", server bisa mengabaikannya, tetapi itu mengekspresikan keinginan klien.
DUzun

Jawaban saya sebenarnya dapat ditingkatkan untuk menjelaskan bagaimana klien dan server menegosiasikan ini. Jangan ragu untuk menyarankan peningkatan jika Anda mau.
Simon East

5

Ini menjelaskan semuanya:

HTTP-Content-Security-Policy (CSP) arahan upgrade-insecure-request menginstruksikan agen pengguna untuk memperlakukan semua URL tidak aman situs (yang dilayani melalui HTTP) seolah-olah mereka telah diganti dengan URL aman (yang dilayani melalui HTTPS). Arahan ini ditujukan untuk situs web dengan sejumlah besar URL warisan tidak aman yang perlu ditulis ulang.

Arahan upgrade-insecure-permintaan dievaluasi sebelum memblokir-semua-campuran-konten dan jika diatur, yang terakhir secara efektif adalah no-op. Disarankan untuk mengatur satu arahan atau yang lain, tetapi tidak keduanya.

Arahan upgrade-insecure-request tidak akan memastikan bahwa pengguna yang mengunjungi situs Anda melalui tautan di situs pihak ketiga akan ditingkatkan ke HTTPS untuk navigasi tingkat atas dan karenanya tidak menggantikan header Strict-Transport-Security (HSTS), yang harus tetap diatur dengan usia maksimal yang sesuai untuk memastikan bahwa pengguna tidak terkena serangan stripping SSL.

Sumber: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.