Bir HTTP (HTTPS olmayan) siteye POST isteği gönderdim, Chrome'un Geliştirici Araçları'nda isteği inceledim ve sunucuya göndermeden önce kendi üstbilgisini eklediğini gördüm:

Upgrade-Insecure-Requests: 1

Üzerinde arama yaptıktan sonra Upgrade-Insecure-Requests, yalnızca bu üstbilgiyi gönderen sunucu hakkında bilgi bulabilirim :

Content-Security-Policy: upgrade-insecure-requests

Bu benim durumumda, MÜŞTERİ üstbilgi gönderiyor beri çok farklı değerle alakalıdır, ama görünüyor Request ben ilgili başlık gönderirken SUNUCU ilgili tespit ettiğimiz bilgiler tüm oysa Tepki .

Peki, Chrome (44.0.2403.130 m) neden isteğimi ekliyor Upgrade-Insecure-Requestsve ne yapıyor?

2016-08-24 Güncellemesi:

Bu başlık o zamandan beri bir W3C Aday Önerisi olarak eklendi ve artık resmi olarak tanınıyor.

Bu soruya henüz yaklaşan ve kafası karışanlar için Simon East'in mükemmel cevabı bunu iyi açıklıyor.

Upgrade-Insecure-Requests: 1Başlık olarak kullanılan HTTPS: 1 önceki W3C Taslak içerisinde ve değiştirildi sessizce değişim resmen kabul olmadan önce Chrome tarafından.

(Bu soru, bu üstbilgide resmi bir belge bulunmadığı ve bu üstbilgiyi gönderen tek tarayıcı Chrome olduğu zaman bu geçiş sırasında sorulmuştur.)

Kısa cevap: Content-Security-Policy: upgrade-insecure-requeststarayıcının onu desteklediğini (ve aslında tercih ettiğini) gösteren yanıt üstbilgisiyle yakından ilgilidir .

Beni 30 dakika Googling aldı, ama sonunda W3 spec gömülü bulundu.

Bu karışıklık, spesifikasyondaki başlık olduğu HTTPS: 1ve Chromium'un bu şekilde uyguladığı için geliyor, ancak bundan sonra kötü kodlanmış (özellikle WordPress ve WooCommerce) birçok web sitesi kırıldıktan sonra Chromium ekibi özür diledi:

"Kırılma için özür dilerim; görünüşe göre dev ve beta sırasındaki geri bildirime dayalı etkiyi hafife aldım."
- Mike West, Chrome Sayı 501842'de

Düzeltmeleri yeniden adlandırmaktı Upgrade-Insecure-Requests: 1ve özellik o zamandan beri eşleşecek şekilde güncellendi.

Her neyse, işte W3 spesifikasyonunun açıklaması (o zaman göründüğü gibi) ...

HTTPSHTTP isteği başlık alanı sunucuya bir sinyal gönderir müşterinin tercihi ifade eden şifreli ve kimliği doğrulanmış tepki için ve bu başarıyla yükseltme-güvensiz-istekler direktifi işleyebilir sağlamak için mümkün olduğunca kesintisiz olarak bu tercihi yapmak için.

...

Bir sunucu bir HTTP isteğinin üstbilgilerinde bu tercihle karşılaştığında, kullanıcıyı istenen kaynağın güvenli bir şekilde temsiline yönlendirmelidir.

Bir sunucu bir HTTPS isteğinin başlıklarında bu tercihle karşılaştığında Strict-Transport-Security, isteğin ana bilgisayarı HSTS güvenli veya koşullu olarak HSTS güvenli ise [RFC6797] yanıtta bir başlık içermelidir.

Bu her şeyi açıklıyor:

HTTP Content-Security-Policy (CSP) yükseltme-güvensizlik-istekleri yönergesi, kullanıcı aracılara bir sitenin tüm güvenli olmayan URL'lerini (HTTP üzerinden sunulanlar) güvenli URL'lerle (HTTPS üzerinden sunulanlar) değiştirilmiş gibi ele almalarını bildirir. Bu yönerge, yeniden yazılması gereken çok sayıda güvensiz eski URL'ye sahip web siteleri için hazırlanmıştır.

Yükseltme-güvensiz-istekleri yönergesi, blok-tüm-karışık içerikten önce değerlendirilir ve ayarlanmışsa, ikincisi etkin bir şekilde işlem yapılmaz. Bir yönerge veya diğerinin ayarlanması önerilir, ancak her ikisinin birden ayarlanmaması önerilir.

Yükseltme-güvensiz istekler yönergesi, üçüncü taraf sitelerdeki bağlantılar aracılığıyla sitenizi ziyaret eden kullanıcıların üst düzey gezinme için HTTPS'ye yükseltilmesini ve dolayısıyla Sıkı Aktarım Güvenliği (HSTS) üstbilgisinin yerini almamasını sağlamaz. yine de kullanıcıların SSL sıyırma saldırılarına maruz kalmadığından emin olmak için uygun bir maksimum yaşla ayarlanmalıdır.

Kaynak: https://developer.mozilla.org/tr-TR/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests