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

221

Ho fatto una richiesta POST a un sito HTTP (non HTTPS), ho ispezionato la richiesta negli Strumenti per sviluppatori di Chrome e ho scoperto che ha aggiunto la propria intestazione prima di inviarla al server:

Upgrade-Insecure-Requests: 1

Dopo aver effettuato una ricerca Upgrade-Insecure-Requests, posso solo trovare informazioni sul server che invia questa intestazione:

Content-Security-Policy: upgrade-insecure-requests

Questo sembra correlato, ma comunque molto diverso poiché nel mio caso, il CLIENTE sta inviando l'intestazione nella Richiesta , mentre tutte le informazioni che ho trovato riguardano il SERVER che invia l'intestazione correlata in una Risposta .

Quindi perché Chrome (44.0.2403.130 m) si aggiunge Upgrade-Insecure-Requestsalla mia richiesta e cosa fa?

Aggiornamento 24-08-2016:

Da allora questa intestazione è stata aggiunta come raccomandazione del candidato W3C ed è ora ufficialmente riconosciuta.

Per coloro che hanno appena incontrato questa domanda e sono confusi, l' eccellente risposta di Simon East lo spiega bene.

L' Upgrade-Insecure-Requests: 1intestazione era HTTPS: 1 nel precedente Working Draft del W3C ed è stata rinominata tranquillamente da Chrome prima che la modifica venisse ufficialmente accettata.

(Questa domanda è stata posta durante questa transizione quando non c'era documentazione ufficiale su questa intestazione e Chrome era l'unico browser a inviare questa intestazione.)

— user193130
fonte

Anche Firefox lo fa.

— dakab,

Deve essere nuovo; Faccio prima lo sviluppo su Firefox e questa intestazione sicuramente non è stata inviata da Firefox l'anno scorso.

— user193130

Risposte:

274

Risposta breve: è strettamente correlata all'intestazione della Content-Security-Policy: upgrade-insecure-requestsrisposta, a indicare che il browser lo supporta (e in effetti lo preferisce).

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

La confusione deriva dal fatto che l'intestazione era nelle specifiche HTTPS: 1, ed è così che Chromium l'ha implementata, ma dopo questo ha rotto molti siti Web che erano scarsamente codificati (in particolare WordPress e WooCommerce) il team Chromium si è scusato:

"Mi scuso per la rottura; apparentemente ho sottovalutato l'impatto in base al feedback durante dev e beta."
- Mike West, in Chrome Numero 501842

La loro soluzione era di rinominarla Upgrade-Insecure-Requests: 1e da allora le specifiche sono state aggiornate per corrispondere.

Comunque, ecco la spiegazione delle specifiche W3 (come appariva al momento) ...

Il HTTPScampo dell'intestazione della richiesta HTTP invia un segnale al server che esprime la preferenza del client per una risposta crittografata e autenticata e che può gestire correttamente la direttiva upgrade-insecure-richieste al fine di rendere tale preferenza il più semplice possibile da fornire.

...

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

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

— Simon Oriente
fonte

Non riesco a capirlo. Ti sto a.comreindirizzando b.com, fornendo questa intestazione b.come inviando alcune informazioni. Se non sei sotto un canale sicuro per b.com, può già accadere un attacco di fiuto, perché ho inviato dati a b.comfianco della mia richiesta. Puoi guidarci verso un semplice scenario su come rendere le connessioni più sicure per gli utenti?

— Saeed Neamati,

@SaeedNeamati In una prospettiva molto rigorosa non rende nulla di più sicuro. Se hai i normali requisiti di sicurezza, devi prima assicurarti di connetterti tramite HTTPS e non fare affidamento su questo. Detto questo, vorrei descrivere questo nel contesto del concetto di " fiducia al primo utilizzo ", che fa l'aiuto passivamente.

— TNE

Lo vedo più come il desiderio del cliente che come strumento di sicurezza. È come l'intestazione "DNT", il server potrebbe ignorarlo, ma tuttavia esprime la volontà del cliente.

— DUzun,

La mia risposta potrebbe effettivamente essere migliorata per spiegare correttamente come il client e il server lo negoziano. Sentiti libero di suggerire miglioramenti, se lo desideri.

— Simon East,

Questo spiega tutto:

La direttiva di aggiornamento delle richieste non sicure di HTTP Content-Security-Policy (CSP) ordina agli agenti utenti di trattare tutti gli URL non sicuri di un sito (quelli offerti su HTTP) come se fossero stati sostituiti con URL sicuri (quelli offerti su HTTPS). Questa direttiva è destinata ai siti Web con un numero elevato di URL legacy non sicuri che devono essere riscritti.

La direttiva upgrade-insecure-request viene valutata prima del blocco di tutti i contenuti misti e, se impostata, quest'ultima è effettivamente una no-op. Si consiglia di impostare una direttiva o l'altra, ma non entrambe.

La direttiva upgrade-insecure-request non garantirà che gli utenti che visitano il tuo sito tramite link su siti di terze parti vengano aggiornati a HTTPS per la navigazione di livello superiore e quindi non sostituisce l'intestazione Strict-Transport-Security (HSTS), che dovrebbe comunque essere impostato con un'età massima appropriata per garantire che gli utenti non siano soggetti ad attacchi di stripping SSL.

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

— Basil Musa
fonte