it-swarm.com.de

Wird dasselbe von HTTP und HTTPS abgerufene JavaScript vom Browser separat zwischengespeichert?

Angenommen, ein Webserver unterstützt sowohl HTTP als auch HTTPS. Wenn ein Browser dasselbe JavaScript mit einem HTTP-GET und einem HTTPS-GET abruft und das JavaScript zwischengespeichert werden kann, speichert der Browser dann zwei Kopien desselben JavaScript zwischen?

Der Grund, den ich frage, ist, dass ein Angreifer, wenn nur eine Kopie zwischengespeichert wird, das Opfer zuerst dazu verleiten könnte, JavaScript über HTTP herunterzuladen und dabei zu kompromittieren, was zu einem Cache-Vergiftungsangriff führt.

42
SamTest

Ressourcen werden anhand ihrer URL und des Protokolls (http:// oder https://) ist Teil der URL. Da sich das Protokoll unterscheidet, muss sich auch die URL unterscheiden, und Sie haben zwei separate Cache-Einträge.

69
MSalters

Es ist vollkommen in Ordnung, wenn ein http:// und ein https:// Ressource liefert unterschiedliche Daten, auch wenn alle außer der Zugriffsmethode gleich sind. Zum Beispiel Zugriff auf http:// führt heute häufig zu einer Umleitungsantwort beim Zugriff auf https:// liefern den wirklichen Inhalt. Ein Browser speichert diese Ressourcen daher unabhängig voneinander zwischen.

46
Steffen Ullrich

Zusammenfassung:

  • Der primäre Cache-Schlüssel für jeden standardkonformen Browser ist ein absoluter URI
  • Der absolute URI beginnt http: für alle unsicheren Anfragen und https: für alle sicheren Anfragen
  • Folglich kann eine sicher abgerufene Ressource niemals denselben Cache-Schlüssel verwenden wie eine unsicher abgerufene Ressource

Der aktuelle Standard für HTTP ist auf mehrere "RFC" -Dokumente aufgeteilt, wobei RFC 7234 ausschließlich dem Caching gewidmet ist, da dies mit einer hohen Komplexität verbunden ist.

In Abschnitt 2, "Übersicht über den Cache-Betrieb", finden Sie diese Zusammenfassung:

Der primäre Cache-Schlüssel besteht aus der Anforderungsmethode und dem Ziel-URI. Da die heute gebräuchlichen HTTP-Caches in der Regel auf das Zwischenspeichern von Antworten auf GET beschränkt sind, lehnen viele Caches einfach andere Methoden ab und verwenden nur den URI als primären Cache-Schlüssel.

Dies wird formeller im ersten Punkt in Abschnitt 4 dargelegt, in dem es heißt:

Bei einer Anforderung darf ein Cache eine gespeicherte Antwort NICHT wiederverwenden, es sei denn, [...] der präsentierte effektive Anforderungs-URI (Abschnitt 5.5 von RFC7230) stimmt mit dem der gespeicherten Antwort überein, [...]

Abschnitt 5.5 von RFC 72 beginnt mit den Worten

Für einen Benutzeragenten ist der effektive Anforderungs-URI der Ziel-URI.

Ein Browser ist ein "Benutzeragent". Dies ist also der Fall, um den es hier geht. "Ziel-URI" ist definiert in Abschnitt 5.1 :

Eine URI-Referenz (Abschnitt 2.7) wird normalerweise als Kennung für die "Zielressource" verwendet, die ein Benutzeragent in seine absolute Form auflösen würde, um die "Ziel-URI" zu erhalten. Der Ziel-URI schließt gegebenenfalls die Fragmentkomponente der Referenz aus, da Fragment-IDs für die clientseitige Verarbeitung reserviert sind (RFC3986, Abschnitt 3.5).

Die generische Definition eines URI ist in RFC 3986 , und HTTP-spezifische Bedenken nehmen drei Seiten von RFC 7230 ein. Der für unsere Zwecke relevanteste Teil ist RFC 3986, Abschnitt 4.1 welches diese Grammatik für absolute URIs definiert:

absolute-URI = Schema ":" hier-part ["?" Abfrage]

Beachten Sie vor allem, dass scheme ein obligatorischer Bestandteil jeder absoluten URI ist. Da HTTP-URIs immer das Schema http und HTTPS-URIs immer das Schema https verwenden, bedeutet dies, dass ihre absoluten URIs und damit ihre "primären Cache-Schlüssel" in einem Browser niemals kollidieren können.


Andere Antworten haben Ports erwähnt. RFC 7230, Abschnitt 2.7.1 definiert http URIs so, dass sie einen Abschnitt "Autorität" enthalten, der in [RFC 3986, Abschnitt 3.2] definiert ist:

authority = [Benutzerinfo "@"] Host [":" Port]

Der Port ist optional, wobei RFC 7230, Abschnitt 2.7.1 den Standard für das URI-Schema http definiert:

Wenn die Port-Unterkomponente leer oder nicht angegeben ist, ist TCP Port 80 (der reservierte Port für WWW-Dienste) die Standardeinstellung.

Und der folgende Abschnitt definiert den Standard für "https":

Alle oben aufgeführten Anforderungen für das "http" -Schema sind auch Anforderungen für das "https" -Schema, mit der Ausnahme, dass TCP Port 443 ist die Standardeinstellung, wenn die Port-Unterkomponente leer oder nicht angegeben ist, und ...

Daraus folgt:

  • Jede HTTP-Anforderung, die sich nicht an Port 80 befindet, muss eine Portnummer in ihrem absoluten URI enthalten
  • Jede HTTPS-Anforderung, die sich nicht an Port 443 befindet, muss eine Portnummer in ihrem absoluten URI enthalten
  • Keine zwei Anforderungen mit unterschiedlichen angegebenen Portnummern haben denselben Cache-Schlüssel, da sie unterschiedliche absolute URIs haben

Somit würden diese URIs alle separat zwischengespeichert:

Das einzige, was mir nicht klar ist, ist, ob der Browser URIs normalisieren soll, darf oder muss, die explizit den Port erwähnen, der sowieso der Standard wäre. Mit anderen Worten, ob diese beiden URIs separat zwischengespeichert werden oder nicht:

Ich kann mir keine praktischen Konsequenzen für die Normalisierung dieser auf denselben Cache-Schlüssel vorstellen, da durch die obigen Definitionen garantiert wird, dass sie dieselbe Ressource darstellen.

8
IMSoP

Ja, da es sich um unterschiedliche Netzwerkziele handelt. Der TCP-Port wird bei Verwendung des Standardports nicht in der Positionsleiste angezeigt.

HTTP ist standardmäßig TCP-Port 80. Www.example.com:80

Https ist standardmäßig TCP-Port 443 Www.example.com:443

Selbst wenn die Domain und die IP identisch sind, sind die Ports nicht identisch. Aus der Browserperspektive kommuniziert der Browser mit verschiedenen Websites.

UPDATE

Das Netzwerk beeinflusst es nicht so sehr wie das S im https. Es ist auch eine andere URI.

2
Jonathan

Abgesehen von der Tatsache, dass in der Spezifikation klar ist, dass unterschiedliche URLs als unterschiedliche Ressourcen behandelt werden sollten, glauben Sie nicht, dass dies inzwischen jemand bemerkt und ausgenutzt hätte, wenn dies nicht der Fall wäre? Schließlich sind alle Probleme, die durch Cookies aufgedeckt werden (und die durch die "sichere" Flagge gekennzeichnet sind), seit 20 Jahren oder länger bekannt.

Der Browser muss also beide URLs abrufen. Es ist denkbar, dass ein Cache eine einzelne Kopie einer Datei enthält, die von verschiedenen Quellen heruntergeladen, aber über verschiedene Schlüssel aufgerufen wurde - oder dass diese Deduplizierung tiefer im Dateisystem auftritt (Deduplizierung). Dies würde aber nur passieren nach der Cache (oder das Dateisystem) hatte festgestellt, dass die Dateien gleich waren.

2
symcbean

Ja, das sind unterschiedliche Ursprünge. Obwohl es sehr wahrscheinlich ist, dass sie denselben Inhalt bereitstellen, können sie technisch völlig unterschiedliche Inhalte bereitstellen. Aus diesem Grund darf der Browser sie nicht als dieselbe Ressource behandeln.

0
Aaron Cicali

Aus serverseitiger Sicht kann dieselbe URL (z. B. www.test.com) in verschiedenen Protokollen (z. B. HTTP oder HTTPS) eine andere Dateiquelle verwenden. Eine URL mit TLS kann also eine völlig andere Website ausgeben als die URL ohne TLS. Dies allein lässt mich denken, dass Browser nicht für beide Dateien denselben Cache verwenden.

0
Martin