webentwicklung-frage-antwort-db.com.de

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

Ich habe eine POST -Anforderung an eine HTTP-Site (Nicht-HTTPS) gesendet, die Anforderung in den Chrome-Entwicklertools überprüft und festgestellt, dass sie einen eigenen Header hinzugefügt hat, bevor sie an den Server gesendet wurde:

Upgrade-Insecure-Requests: 1

Nach einer Suche in Upgrade-Insecure-Requests kann ich nur Informationen über den Server finden, der diese Header sendet:

Content-Security-Policy: upgrade-insecure-requests

Dies scheint verwandt zu sein, ist aber immer noch sehr unterschiedlich, da der KUNDE in meinem Fall den Header in der -Anforderung sendet, während sich alle Informationen, die ich gefunden habe, auf den SERVER beziehen, der die verwandten Daten sendet Header in einer Antwort .


Warum fügt Chrome (44.0.2403.130 m) meiner Anfrage Upgrade-Insecure-Requests hinzu, und was macht es?


Update 24.08.2016:

Dieser Header wurde inzwischen als W3C Candidate Recommendation hinzugefügt und ist nun offiziell anerkannt.

Für diejenigen, die gerade auf diese Frage gestoßen sind und verwirrt sind, erklärt das ausgezeichnete Antwort von Simon East sie gut.

Der Upgrade-Insecure-Requests: 1 -Header war HTTPS: 1im vorherigen W3C-Arbeitsentwurf und wurde leise umbenannt von Chrome, bevor die Änderung offiziell akzeptiert wurde.

(Diese Frage wurde während dieses Übergangs gestellt, als es keine offizielle Dokumentation zu diesem Header gab und Chrome der einzige Browser war, der diesen Header gesendet hat.)

210
user193130

Kurze Antwort: Es hängt eng mit dem Antwortheader Content-Security-Policy: upgrade-insecure-requests zusammen und zeigt an, dass der Browser dies unterstützt (und es sogar bevorzugt).

Ich brauchte 30 Minuten zum Googeln, fand es aber schließlich in der W3-Spezifikation vergraben.

Die Verwirrung kommt, weil der Header in der Spezifikation HTTPS: 1 war, und so hat Chromium es implementiert, aber danach hat viele Websites kaputt gemacht, die schlecht codiert waren (insbesondere WordPress und WooCommerce) entschuldigte sich das Chromium-Team:

"Ich entschuldige mich für den Bruch. Ich habe die Auswirkungen, die sich aus den Rückmeldungen während der Entwicklung und der Beta ergeben, offensichtlich unterschätzt."
- Mike West, in Chrome-Ausgabe 501842

Ihr Fix bestand darin, es in Upgrade-Insecure-Requests: 1 umzubenennen, und die Spezifikation wurde seitdem entsprechend aktualisiert.

Wie auch immer, hier ist die Erklärung aus der W3-Spezifikation (wie es zu der Zeit erschien) ...

Das HTTP-Anforderungsheaderfeld HTTPS sendet ein Signal an den Server , das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt, und das Es kann die Upgrade-Insecure-Requests-Direktive erfolgreich verarbeiten, um diese Präferenz so nahtlos wie möglich zu gestalten.

...

Wenn ein Server diese Einstellung in den Headern einer HTTP-Anforderung findet, MUSS er den Benutzer zu einer potenziell sicheren Darstellung der angeforderten Ressource umleiten.

Wenn ein Server auf diese Einstellung in den Headern einer HTTPS-Anforderung stößt, MUSS er einen Header Strict-Transport-Security in die Antwort einfügen, wenn der Host der Anforderung HSTS-sicher oder bedingt HSTS-sicher ist [RFC6797].

267
Simon East

Das erklärt das Ganze:

Die CSP-Direktive (HTTP Content-Security-Policy) für Upgrade-Insecure-Requests weist Benutzeragenten an, alle unsicheren URLs einer Site (die über HTTP bereitgestellt werden) so zu behandeln, als ob sie durch sichere URLs (die über HTTPS bereitgestellt werden) ersetzt worden wären. Diese Direktive ist für Websites mit einer großen Anzahl unsicherer veralteter URLs gedacht, die neu geschrieben werden müssen.

Die Upgrade-Insecure-Requests-Direktive wird vor dem Block-All-Mixed-Content ausgewertet, und wenn sie gesetzt ist, ist letzterer praktisch ein No-Op. Es wird empfohlen, die eine oder die andere Anweisung festzulegen, jedoch nicht beide.

Die Direktive "Upgrade-insecure-Requests" garantiert nicht, dass Benutzer, die Ihre Site über Links auf Sites von Drittanbietern besuchen, für die Navigation der obersten Ebene auf HTTPS aktualisiert werden, und ersetzt daher nicht den Header "Strict-Transport-Security (HSTS)" sollte immer noch ein angemessenes Höchstalter festgelegt werden, um sicherzustellen, dass Benutzer keinen SSL-Stripping-Angriffen ausgesetzt sind.

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

3
Basil Musa