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

220

Ich habe eine POST-Anforderung an eine HTTP-Site (Nicht-HTTPS) gesendet, die Anforderung in den Entwicklertools von Chrome ü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 am Upgrade-Insecure-Requestskann ich nur Informationen über den Server finden, der diesen Header sendet :

Content-Security-Policy: upgrade-insecure-requests

Dies scheint verwandt zu sein, ist aber immer noch sehr unterschiedlich, da in meinem Fall der CLIENT den Header in der Anfrage sendet , während alle Informationen, die ich gefunden habe, den SERVER betreffen, der den zugehörigen Header in einer Antwort sendet .

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

Update 24.08.2016:

Dieser Header wurde inzwischen als W3C-Kandidatenempfehlung hinzugefügt und ist nun offiziell anerkannt.

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

Der Upgrade-Insecure-Requests: 1Header befand sich früher HTTPS: 1 im vorherigen W3C-Arbeitsentwurf und wurde von Chrome stillschweigend umbenannt, 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.)

— user193130
quelle

Firefox macht es auch.

— Dakab

Muss neu sein; Ich entwickle zuerst Firefox und dieser Header wurde letztes Jahr definitiv nicht von Firefox gesendet.

— user193130

Antworten:

274

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

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

Die Verwirrung entsteht, weil der Header in der Spezifikation lautete HTTPS: 1und Chromium dies so implementierte. Nachdem jedoch viele schlecht codierte Websites (insbesondere WordPress und WooCommerce) beschädigt wurden, entschuldigte sich das Chromium-Team:

"Ich entschuldige mich für den Bruch. Ich habe anscheinend die Auswirkungen aufgrund des Feedbacks während der Entwicklung und der Beta unterschätzt."
- Mike West in der Chrome-Ausgabe 501842

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

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

Das HTTPSHTTP-Anforderungsheaderfeld sendet ein Signal an den Server , das die Präferenz des Clients für eine verschlüsselte und authentifizierte Antwort ausdrückt und besagt, dass es die Direktive für unsichere Upgrade-Anforderungen erfolgreich verarbeiten kann , um diese Präferenz so nahtlos wie möglich bereitzustellen.

...

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

Wenn ein Server diese Einstellung in den Headern einer HTTPS-Anforderung findet, sollte er einen Strict-Transport-SecurityHeader in die Antwort aufnehmen, wenn der Host der Anforderung HSTS-sicher oder bedingt HSTS-sicher ist [RFC6797].

— Simon East
quelle

Ich verstehe es nicht. Ich bin a.comund leite Sie weiter b.com, während Sie diesen Header bereitstellen b.comund einige Informationen senden. Wenn Sie sich nicht unter einem sicheren Kanal befinden b.com, kann es bereits zu einem Schnüffelangriff kommen, da ich b.comneben meiner Anfrage Daten an gesendet habe . Können Sie uns zu einem einfachen Szenario führen, wie Verbindungen für Benutzer sicherer werden?

— Saeed Neamati

@SaeedNeamati Unter einer sehr strengen Perspektive macht es nichts sicherer. Wenn Sie normale Sicherheitsanforderungen haben, müssen Sie sicherstellen, dass Sie zuerst eine Verbindung über HTTPS herstellen und sich nicht darauf verlassen. That being said, ich würde das in Zusammenhang mit der Idee der „beschreiben Vertrauen bei der ersten Verwendung “, das tut Hilfe passiv.

— Der

Ich sehe dies eher als Kundenwunsch als als Sicherheitstool. Es ist wie ein "DNT" -Header, der Server könnte ihn ignorieren, aber er drückt den Willen des Kunden aus.

— DUzun

Meine Antwort könnte tatsächlich verbessert werden, um richtig zu erklären, wie der Client und der Server dies aushandeln. Wenn Sie möchten, können Sie gerne Verbesserungen vorschlagen.

— Simon East

Das erklärt das Ganze:

Die Richtlinie zum Aktualisieren unsicherer Anforderungen für HTTP-Inhaltssicherheitsrichtlinien (CSP) weist Benutzeragenten an, alle unsicheren URLs einer Site (die über HTTP bereitgestellt werden) so zu behandeln, als wären sie durch sichere URLs (die über HTTPS bereitgestellt wurden) ersetzt worden. Diese Richtlinie ist für Websites mit einer großen Anzahl unsicherer Legacy-URLs gedacht, die neu geschrieben werden müssen.

Die Direktive zum Aktualisieren unsicherer Anforderungen wird vor dem Blockieren aller gemischten Inhalte ausgewertet. Wenn sie festgelegt ist, ist letzterer praktisch ein No-Op. Es wird empfohlen, die eine oder die andere Richtlinie festzulegen, jedoch nicht beide.

Die Richtlinie zum Aktualisieren unsicherer Anforderungen stellt nicht sicher, dass Benutzer, die Ihre Website über Links auf Websites von Drittanbietern besuchen, für die Navigation auf oberster Ebene auf HTTPS aktualisiert werden, und ersetzt daher nicht den HSTS-Header (Strict-Transport-Security) sollte immer noch mit einem angemessenen 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

— Basilikum Musa
quelle