Was ist der HTTP-Header "Upgrade-Insecure-Requests"?

Question

Ich habe eine POST-Anfrage an einen HTTP (nicht HTTPS) Website, die Anfrage in Chrome Developer Tools untersucht und festgestellt, dass es an den Server vor dem Senden seiner eigenen Header hinzugefügt:

Upgrade-Insecure-Requests: 1 

Nach tun Suche auf Upgrade-Insecure-Requests, kann ich nur information über den Server finden Senden this Header:

Content-Security-Policy: upgrade-insecure-requests 

Dies scheint verwandt, aber immer noch sehr unterschiedlich, da in meinem Fall ist der Kunde den Header in der Anfrage Senden, wobeia s Alle Informationen, die ich gefunden habe, betreffen den SERVER, der den zugehörigen Header in einer Antwort sendet.

---

Warum ist Chrome (44.0.2403.130 m) Zugabe Upgrade-Insecure-Requests auf meine Anfrage und was tut sie?

---

-Update 2016.08.24:

Dieser Header hinzugefügt, da wurde als W3C Candidate Recommendation und jetzt offiziell anerkannt wird.

Für diejenigen, die gerade auf diese Frage gestoßen sind und verwirrt sind, erklärt die excellent answer von Simon East es gut.

Der Upgrade-Insecure-Requests: 1 Header verwendet werden HTTPS: 1in the previous W3C Working Draft und wurde leise von Chrome umbenannt, bevor die Änderung offiziell akzeptiert wurde.

(Diese Frage wurde während dieses Übergangs gefragt, wenn es auf diesem Header keine offizielle Dokumentation waren und Chrome war der einzige Browser, der diesen Header gesendet.)

Answer 1

Kurze Antwort: es dem Content-Security-Policy: upgrade-insecure-requests Antwort-Header eng verwandt ist, Angeben, dass der Browser es unterstützt (und es tatsächlich bevorzugt).

Es dauerte 30 Minuten Googeln, aber ich fand es schließlich in der W3-Spezifikation begraben.

Die Verwirrung kommt, da der Header in der Spezifikation HTTPS: 1 war, und dies ist, wie Chromium es umgesetzt, danach aber broke lots of websites that were poorly coded (insbesondere Wordpress und WooCommerce) das Chromium-Team entschuldigte:

„Mich für das entschuldigen "Ich habe die Auswirkungen aufgrund der Rückmeldungen während der Entwicklung und der Beta-Phase anscheinend unterschätzt."
- Mike West in Chrome Issue 501842

Ihre fix war es Upgrade-Insecure-Requests: 1 zu umbenennen, und die Spezifikation seit aktualisiert wurde übereinstimmen.

Wie auch immer, hier ist die Erklärung von the W3 spec (as it appeared at the time) ...

Das HTTPS HTTP-Request-Header-Feld sendet ein Signal an den Server des Kunden bevorzugt für eine verschlüsselte und authentifizierte Antwort ausdrückt, und dass kann sie erfolgreich die Upgrade-unsicher-Anforderungen verarbeitet um Richtlinie zu machen diese Präferenz so nahtlos wie möglich zu bieten.

...

Wenn ein Server diese Präferenz in einem Header der HTTP-Anforderung trifft, sollte es den Benutzer auf eine potentiell sichere Darstellung der Ressource wird angefordert umleiten.

Wenn ein Server diese Voreinstellung in einer HTTPS-Anforderung des Header findet, soll es einen Strict-Transport-Security Header in der Antwort enthält, wenn die Host HSTS-Safe oder bedingt HSTS-safe [RFC6797] ist die Anfrage.

Answer 2

Dies erklärt die ganze Sache:

Die HTTP-Content-Security-Politik (CSP) upgrade-unsicher-Anfragen Richtlinie Benutzeragenten anweist, alle eine Website unsicheren URLs (diejenigen, bedient zu behandeln über HTTP), als ob sie durch sichere URLs (die über HTTPS bedient wurden) ersetzt wurden. Diese Richtlinie ist für Websites mit einer großen Anzahl unsicherer Legacy-URLs gedacht, die umgeschrieben werden müssen.

Die upgrade-unsecure-requirements-Anweisung wird vor block-all-mixed-content ausgewertet, und wenn sie gesetzt ist, ist letzteres effektiv ein no-op. Es wird empfohlen, eine Richtlinie oder die andere, aber nicht beide zu setzen.

Die Upgrade-unsicher-Anfragen Richtlinie gewährleistet nicht, dass die Nutzer Ihre Website über Links auf Websites von Drittanbietern sind, werden für die Top-Level-Navigation und somit nicht den Strict-Transport- ersetzt nicht auf HTTPS aufgerüstet werden Security (HSTS) -Header, der immer noch auf mit einem entsprechenden Höchstalter festgelegt werden sollte, um sicherzustellen, dass Benutzer SSL-Stripping-Angriffen nicht unterliegen.

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