Was ist der Unterschied zwischen einer 302- und einer 307-Weiterleitung?

Was ist der Unterschied zwischen a 302 FOUND und einer 307 TEMPORARY REDIRECTHTTP-Antwort?

Die W3-Spezifikation scheint darauf hinzudeuten, dass beide für temporäre Weiterleitungen verwendet werden und keine zwischengespeichert werden kann, es sei denn, die Antwort erlaubt dies ausdrücklich.

Die Bedenken Unterschied Umleitung POST, PUTund DELETEAnfragen und was die Erwartungen des Servers sind für den User - Agent - Verhalten ( RFC 2616):

Hinweis: RFC 1945 und RFC 2068 geben an, dass der Client die Methode für die umgeleitete Anforderung nicht ändern darf. Die meisten vorhandenen Benutzeragentenimplementierungen behandeln 302 jedoch so, als wäre es eine 303-Antwort, und führen unabhängig von der ursprünglichen Anforderungsmethode ein GET für den Feldwert "Standort" durch. Die Statuscodes 303 und 307 wurden für Server hinzugefügt, die eindeutig klarstellen möchten, welche Art von Reaktion vom Client erwartet wird.

Lesen Sie auch den Wikipedia-Artikel über die 30-fachen Umleitungscodes .

307 kam zustande, weil Benutzeragenten als De-facto- Verhalten POST-Anforderungen, die eine 302-Antwort empfangen, entgegennahmen und eine GET-Anforderung an den Standortantwort-Header sendeten.

Das ist das falsche Verhalten - nur ein 303 sollte bewirken, dass aus einem POST ein GET wird. Benutzeragenten sollten sich beim Anfordern der neuen URL an die POST-Methode halten (aber nicht), wenn die ursprüngliche POST-Anforderung eine 302 zurückgegeben hat.

307 wurde eingeführt, damit Server dem Benutzeragenten klar machen können, dass der Client keine Methodenänderung vornehmen sollte , wenn er dem Location-Antwortheader folgt.

Ein gutes Beispiel für die 307 Internal RedirectAktion ist, wenn Google Chrome auf einen HTTP-Aufruf einer Domain stößt, von der bekannt ist, dass sie strenge Transportsicherheit erfordert.

Der Browser leitet nahtlos um und verwendet dieselbe Methode wie der ursprüngliche Aufruf.

• 301: permanente Weiterleitung: Die URL ist alt und sollte ersetzt werden. Browser werden dies zwischenspeichern.
  Anwendungsbeispiel: URL verschoben von /register-form.htmlnach signup-form.html.
  Die Methode wird gemäß RFC 7231 in GET geändert: "Aus historischen Gründen kann ein Benutzeragent die Anforderungsmethode für die nachfolgende Anforderung von POST in GET ändern."
• 302: vorübergehende Weiterleitung. Nur für HTTP / 1.0-Clients verwenden. Dieser Statuscode sollte die Methode nicht ändern, aber die Browser haben es trotzdem getan. Der RFC sagt: "Viele Benutzeragenten vor HTTP / 1.1 verstehen [303] nicht. Wenn die Interoperabilität mit solchen Clients ein Problem darstellt, kann stattdessen der Statuscode 302 verwendet werden, da die meisten Benutzeragenten auf eine 302-Antwort reagieren, wie hier beschrieben für 303. " Natürlich können einige Clients es gemäß der Spezifikation implementieren. Wenn also die Interoperabilität mit solchen alten Clients kein wirkliches Problem darstellt, ist 303 besser für konsistente Ergebnisse.
• 303: Temporäre Umleitung, Änderung der Methode in GET.
  Anwendungsbeispiel: Wenn der Browser POST an gesendet hat /register.php, laden Sie jetzt (GET) /success.html.
• 307: temporäre Umleitung, wobei die Anforderung identisch wiederholt wird.
  Anwendungsbeispiel: Wenn der Browser einen POST an gesendet hat /register.php, wird er angewiesen, den POST um zu wiederholen /signup.php.
• 308: permanente Umleitung, wobei die Anforderung identisch wiederholt wird. Wenn 307 das Gegenstück zu "keine Methodenänderung" von 303 ist, ist dieser 308-Status das Gegenstück zu "keine Methodenänderung" von 301.

RFC 7231 (ab 2014) ist sehr gut lesbar und nicht übermäßig ausführlich. Wenn Sie die genaue Antwort wissen möchten, wird eine Lektüre empfohlen. Einige andere Antworten verwenden RFC 2616 aus dem Jahr 1999, aber nichts hat sich geändert.

RFC 7238 gibt den 308-Status an. Es gilt als experimentell, wurde aber bereits 2016 von allen gängigen Browsern unterstützt .

ERWARTET für 302: Die Umleitung verwendet dieselbe Anforderungsmethode POST für NEW_URL

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

ACTUAL für 302, 303: Ändert die Anforderungsmethode für Änderungen von POST nach GET auf NEW_URL um

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)

ACTUAL für 307: Die Umleitung verwendet dieselbe Anforderungsmethode POST für NEW_URL

CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL

302 ist eine temporäre Umleitung, die vom Server generiert wird, während 307 eine interne Umleitungsantwort ist, die vom Browser generiert wird. Interne Umleitung bedeutet, dass die Umleitung automatisch vom Browser intern durchgeführt wird. Grundsätzlich ändert der Browser die eingegebene URL von http zu https, um die Anforderung selbst abzurufen, bevor die Anforderung gestellt wird, sodass die Anforderung einer ungesicherten Verbindung zum Internet niemals erfolgt. Ob der Browser die URL in https ändert oder nicht, hängt von der mit dem Browser vorinstallierten hsts-Preload-Liste ab. Sie können der Liste auch jede Site hinzufügen, die https unterstützt, indem Sie die Domain in die hsts-Preload-Liste Ihres eigenen Browsers unter chrome: //net-internals/#hsts eingeben. Weitere Domain-Domains können von ihren Eigentümern hinzugefügt werden Zum Vorladen der Liste füllen Sie das Formular unter https://hstspreload.org/ aus.Damit es in Browsern für jeden Benutzer vorinstalliert ist, obwohl ich erwähne, dass Sie dies auch besonders für sich selbst tun können.

Lassen Sie mich anhand eines Beispiels erklären:
Ich habe eine Get-Anfrage an http://www.pentesteracademy.com gestellt , die nur https unterstützt, und ich habe diese Domain nicht in meiner hsts-Preload-Liste in meinem Browser, da sich der Websitebesitzer nicht dafür registriert hat mit vorinstallierten hsts Preload-Liste zu kommen. Die GET-Anforderung für eine unsichere Version der Site wird zur sicheren Version umgeleitet (siehe http-Header mit dem Namen location als Antwort auf das obige Bild). Jetzt füge ich die Site meiner eigenen Browser-Preload-Liste hinzu, indem ich ihre Domain im Formular Add hsts domain unter chrome: // net-internals / # hsts hinzufüge, wodurch meine persönliche Preload-Liste in meinem Chrome-Browser geändert wird. Wählen Sie unbedingt include-Subdomains für STS Option dort. Lassen Sie uns jetzt die Anfrage und Antwort für dieselbe Website sehen, nachdem Sie sie zur hsts-Preload-Liste hinzugefügt haben.




Sie können die interne Umleitung 307 dort in Antwortheadern sehen, tatsächlich wird diese Antwort von Ihrem Browser und nicht vom Server generiert.
Die HSTS-Preload-Liste kann auch dazu beitragen, dass Benutzer die unsichere Version der Site nicht erreichen, da 302-Weiterleitungen anfällig für Mitm-Angriffe sind.
Ich hoffe, ich habe Ihnen etwas geholfen, mehr über Weiterleitungen zu verstehen.

Ursprünglich gab es nur 302

| Response               | What browsers should do   |
|------------------------|---------------------------|
| 302 Found              | Redo request with new url |

Die Idee ist, dass:

• Wenn Sie GETan einem Ort eine machen würden, würden Sie Ihre wiederholenGET auf die neue URL
• Wenn Sie POSTan einem Ort eine machen würden, würden Sie Ihre wiederholenPOST auf die neue URL
• Wenn Sie PUTan einem Ort eine machen würden, würden Sie Ihre wiederholenPUT auf die neue URL
• Wenn Sie DELETEan einem Ort eine machen würden, würden Sie Ihre wiederholenDELETE auf die neue URL
• etc

Leider hat jeder Browser es falsch gemacht. Wenn ein immer 302, würden sie wechseln immer GETan der neuen URL, anstatt die Anforderung mit dem erneuten Versuch gleichen Verb ( zB , POST):

• Mosaic hat es falsch gemacht
• Netscape hat die Fehler in Mosaic kopiert. Also haben sie es falsch verstanden
• Internet Explorer hat die Fehler in Netscape kopiert. Also haben sie es falsch verstanden

Es wurde de facto falsch.

Alle Browser haben sich 302geirrt. Also 303und307 wurden geschaffen.

| Antwort | Was sollten Browser tun? Was Browser eigentlich tun | | ------------------------ | ------------------------ --- | --------------------------- | | 302 Gefunden | Anfrage mit neuer URL wiederholen | GET mit neuer URL | | 303 Siehe Andere | GET mit neuer URL | GET mit neuer URL | | 307 Temporäre Weiterleitung | Anfrage mit neuer URL wiederholen | Anfrage mit neuer URL wiederholen |

In Diagrammform

Die 5 verschiedenen Arten von Weiterleitungen:

╔═══════════╤════════════════════════════════════════════════╗
║           │                Switch to GET?                  ║
║ Temporary │          No            │         Yes           ║
╠═══════════╪════════════════════════╪═══════════════════════╣
║ No        │ 308 Permanent Redirect │ 301 Moved Permanently ║
╟───────────┼────────────────────────┼───────────────────────╢
║ Yes       │ 307 Temporary Redirect │ 303 See Other         ║
║           │ 302 Found (intended)   │ 302 Found (actual)    ║
╚═══════════╧════════════════════════╧═══════════════════════╝

Alternative:

| Response                 | Switch to get? | Temporary? |
|--------------------------|----------------|------------|
| 301 Moved Permanently    | No             | No         |
| 302 Found (intended)     | No             | Yes        |
| 302 Found (actual)       | Yes            | Yes        |
| 303 See Other            | Yes            | Yes        |
| 307 Temporary Redirect   | No             | Yes        |
| 308 Permanent Redirect   | No             | No         |

Für Serveradministratoren kann es außerdem wichtig sein, zu beachten, dass Browser dem Benutzer möglicherweise eine Eingabeaufforderung anzeigen, wenn Sie die 307-Umleitung verwenden.

Zum Beispiel * würden Firefox und Opera den Benutzer um Erlaubnis zur Weiterleitung bitten, während Chrome, IE und Safari die Umleitung transparent durchführen würden.

_{* gemäß Bulletproof SSL und TLS (Seite 192).}

In einigen Anwendungsfällen können 307 Weiterleitungen von einem Angreifer missbraucht werden, um die Anmeldeinformationen des Opfers zu erfahren.

Weitere Informationen finden Sie in Abschnitt 3.1 von A Comprehensive formaler Sicherheitsanalyse von OAuth 2.0 .

Die Autoren des obigen Papiers schlagen Folgendes vor:

Fix. Im Gegensatz zum aktuellen Wortlaut des OAuth-Standards ist die genaue Methode der Umleitung kein Implementierungsdetail, sondern für die Sicherheit von OAuth von wesentlicher Bedeutung. Im HTTP-Standard ( RFC 7231 ) ist nur die 303-Umleitung eindeutig definiert, um den Hauptteil einer HTTP-POST-Anforderung zu löschen. Alle anderen HTTP-Umleitungsstatuscodes, einschließlich der am häufigsten verwendeten 302, lassen dem Browser die Option, die POST-Anforderung und die Formulardaten beizubehalten. In der Praxis schreiben Browser normalerweise eine GET-Anforderung neu, wodurch die Formulardaten mit Ausnahme von 307 Weiterleitungen gelöscht werden. Daher sollte der OAuth-Standard 303 Weiterleitungen für die oben genannten Schritte erfordern, um dieses Problem zu beheben.