Che cos'è l'intestazione HTTP "Upgrade-Insecure-Requests"?

Question

Ho fatto una richiesta POST a un (non HTTPS) sito HTTP, ispezionato la richiesta nei tool di sviluppo di Chrome, e ha scoperto che ha aggiunto la propria intestazione prima di inviarlo al server:

Upgrade-Insecure-Requests: 1 

Dopo aver fatto una Ricerca su Upgrade-Insecure-Requests, posso trovare solo information relative al server di invio this intestazione:

Content-Security-Policy: upgrade-insecure-requests 

Questo sembra essere legata, ma ancora molto diversa, in quanto nel mio caso, il client invia l'intestazione nella Richiesta, wherea s tutte le informazioni che ho trovato riguardano il SERVER che invia la relativa intestazione in una risposta .

---

Perché, dunque, Chrome (44.0.2403.130 m) aggiungendo Upgrade-Insecure-Requests alla mia richiesta e che cosa fa?

---

Aggiornamento 2016/08/24:

Questa intestazione da allora è stato aggiunto come W3C Candidate Recommendation ed è ora ufficialmente riconosciuto.

Per coloro che hanno appena trovato questa domanda e sono confusi, lo excellent answer di Simon East lo spiega bene.

Il Upgrade-Insecure-Requests: 1 intestazione usato per essere HTTPS: 1in the previous W3C Working Draft ed è stata ribattezzata tranquillamente da Chrome prima che il cambiamento è diventato ufficialmente accettata.

(Questa domanda è stata posta durante questa fase di transizione, quando c'erano alcuna documentazione ufficiale su questa intestazione e Chrome è stato l'unico browser che ha inviato questa intestazione.)

Answer 1

Risposta breve: è strettamente legato alla testata Content-Security-Policy: upgrade-insecure-requests risposta, indicando che il browser lo supporta (e di fatto lo preferisce).

Mi ci sono voluti 30 minuti di Google, ma alla fine l'ho trovato sepolto nella specifica W3.

La confusione deriva dal fatto che l'intestazione nelle specifiche era HTTPS: 1, e questo è il modo in Chromium implementato, ma dopo questo broke lots of websites that were poorly coded (in particolare WordPress e WooCommerce) la squadra di cromo si scusò:

"Mi scuso per la rottura, a quanto pare ho sottostimato l'impatto sulla base del feedback durante dev e beta. "
- Mike occidentale, in Chrome Issue 501842

loro correzione era di rinominarlo in Upgrade-Insecure-Requests: 1, e le specifiche da allora è stato aggiornato in modo che corrisponda.

In ogni caso, ecco la spiegazione da the W3 spec (as it appeared at the time) ...

Il campo di richiesta di intestazione HTTPS HTTP invia un segnale al server esprimere la preferenza del cliente una risposta crittografata e autenticata, e che è in grado di gestire correttamente l'aggiornamento-precari-richieste Direttiva sui al fine di rendere quella preferenza il più trasparente possibile da fornire.

...

Quando un server incontra questa preferenza nelle intestazioni di una richiesta HTTP, DOVREBBE reindirizzare l'utente a una rappresentazione potenzialmente sicuro della risorsa dalla richiesta.

Quando un server rileva questa preferenza nelle intestazioni di una richiesta HTTPS, DOVREBBE includere un'intestazione Strict-Transport-Security nella risposta se l'host della richiesta è HSTS-safe o condizionatamente HSTS-safe [RFC6797].

Answer 2

Questo spiega il tutto:

Il HTTP Content-Security-Policy (CSP) upgrade-precari-richieste direttiva istruisce i programmi utente per il trattamento di tutti gli URL non sicuri di un sito (quelli serviti su HTTP) come se fossero stati sostituiti con gli URL protetti (quelli pubblicati su HTTPS). Questa direttiva è destinata ai siti web con un numero elevato di URL legacy non sicuri che devono essere riscritti.

La direttiva di richieste di aggiornamento non sicuro viene valutata prima del contenuto block-all-mixed e se è impostato, quest'ultimo è effettivamente un no-op . Si consiglia di impostare una direttiva o l'altra, ma non entrambe.

La direttiva upgrade-insicuri-richieste non farà in modo che gli utenti visitano il tuo sito tramite link su siti di terze parti verranno aggiornati a HTTPS per la navigazione di primo livello e quindi non sostituisce il Strict-Transport- Intestazione di sicurezza (HSTS), che dovrebbe comunque essere impostata su con un'età massima adeguata per garantire che gli utenti non siano soggetti agli attacchi di stripping SSL SSL.

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