Le même JavaScript récupéré par HTTP et HTTPS sera-t-il mis en cache séparément par le navigateur?
Imaginons qu'un serveur Web prend en charge HTTP et HTTPS. Si un navigateur récupère le même JavaScript avec un HTTP GET et un HTTPS GET, et que le JavaScript est compatible avec le cache, le navigateur mettra-t-il en cache deux copies du même JavaScript?
La raison pour laquelle je demande, c'est que si une seule copie est mise en cache, un attaquant pourrait-il d'abord inciter la victime à télécharger JavaScript via HTTP et le compromettre en cours de route, ce qui entraînera une attaque d'empoisonnement du cache?
Les ressources sont mises en cache par leur URL et le protocole (http:// ou https://) fait partie de l'URL. Étant donné que le protocole diffère, l'URL doit également différer et vous disposez de deux entrées de cache distinctes.
C'est parfaitement bien si un http:// et un https:// la ressource fournit des données différentes, même si tout sauf la méthode d'accès est le même. Par exemple, l'accès à http:// entraînera souvent une réponse de redirection lors de l'accès à https:// fournir le vrai contenu. Un navigateur mettra donc ces ressources en cache indépendamment les unes des autres.
Sommaire:
- La clé de cache principale de tout navigateur conforme aux normes est un URI absolu
- L'URI absolu commence
http:pour toutes les demandes non sécurisées ethttps:pour toutes les demandes sécurisées - Par conséquent, une ressource extraite en toute sécurité ne peut jamais utiliser la même clé de cache qu'une ressource extraite de manière non sécurisée
La norme actuelle pour HTTP est divisée en plusieurs documents "RFC", avec RFC 7234 entièrement dédié à la mise en cache, car il y a beaucoup de complexité impliquée.
Dans la section 2, "Présentation du fonctionnement du cache", vous trouverez ce résumé:
La clé de cache principale se compose de la méthode de demande et de l'URI cible. Cependant, étant donné que les caches HTTP couramment utilisés aujourd'hui sont généralement limités à la mise en cache des réponses à GET, de nombreux caches refusent simplement d'autres méthodes et n'utilisent que l'URI comme clé de cache principale.
Ceci est plus formellement énoncé dans le premier point de la section 4, qui dit:
Lorsqu'il est présenté avec une demande, un cache NE DOIT PAS réutiliser une réponse stockée, sauf si [...] l'URI de demande effective présentée (section 5.5 de la RFC7230) celui de la réponse stockée correspond [...]
Section 5.5 de RFC 72 commence par dire
Pour un agent utilisateur, l'URI de demande effective est l'URI cible.
Un navigateur est un "agent utilisateur", c'est donc le cas qui nous intéresse ici. "URI cible" est défini dans la section 5.1 :
Une référence d'URI (section 2.7) est généralement utilisée comme identifiant pour la "ressource cible", qu'un agent utilisateur résoudrait dans sa forme absolue afin d'obtenir "l'URI cible". L'URI cible exclut le composant fragment de la référence, le cas échéant, car les identificateurs de fragment sont réservés pour le traitement côté client (RFC3986, section 3.5).
La définition générique d'un URI se trouve dans RFC 3986 , et les préoccupations spécifiques à HTTP occupent trois pages de RFC 7230. La partie la plus pertinente pour nos besoins est RFC 3986 section 4.1 qui définit cette grammaire pour les URI absolus:
absolu-URI = schéma ":" hier-part ["?" requete ]
Surtout, notez que scheme est une partie obligatoire de tout URI absolu. Puisque les URI HTTP utilisent toujours le schéma http et les URI HTTPS utilisent toujours le schéma https, cela signifie que leurs URI absolus, et donc leurs "clés de cache primaires" dans un navigateur, ne peuvent jamais entrer en collision.
D'autres réponses ont mentionné les ports. RFC 7230, section 2.7.1 définit http URI comme incluant une section "autorité", qui est définie dans [RFC 3986, section 3.2]:
authority = [userinfo "@"] Hôte [":" port]
Le port est facultatif, avec RFC 7230, Section 2.7.1 définissant la valeur par défaut pour le schéma URI http:
Si le sous-composant port est vide ou n'est pas indiqué, TCP port 80 (le port réservé pour les services WWW) est la valeur par défaut.
Et la section suivante définissant la valeur par défaut pour "https":
Toutes les exigences répertoriées ci-dessus pour le schéma "http" sont également des exigences pour le schéma "https", sauf que TCP port 443 est la valeur par défaut si le sous-composant de port est vide ou non indiqué, et ...
Il s'ensuit alors que:
- Toute requête HTTP ne se trouvant pas sur le port 80 doit inclure un numéro de port dans son URI absolu
- Toute demande HTTPS ne se trouvant pas sur le port 443 doit inclure un numéro de port dans son URI absolu
- Deux demandes avec des numéros de port différents spécifiés auront la même clé de cache, car elles auront des URI absolus distincts
Ainsi, ces URI seraient tous mis en cache séparément:
- http://example.com/some/resource (port par défaut 80)
- https://example.com/some/resource (port par défaut 443)
- http://example.com:8000/some/resource (port autre que par défaut)
- https://example.com:8000/some/resource (port autre que par défaut)
- http://example.com:443/some/resource (demande non sécurisée sur le port normalement utilisé pour HTTPS)
- https://example.com:80/some/resource (demande sécurisée sur le port normalement utilisé pour HTTP simple)
La seule chose sur laquelle je ne suis pas clair est de savoir si le navigateur doit, peut ou doit normaliser les URI qui mentionnent explicitement le port qui serait de toute façon le port par défaut. En d'autres termes, si ces deux URI seraient mis en cache séparément ou non:
Je ne peux penser à aucune conséquence pratique de normaliser ces derniers à la même clé de cache, car par les définitions ci-dessus, ils sont garantis pour représenter la même ressource.
Oui, car ce sont des destinations réseau différentes. Le port TCP n'est pas affiché dans la barre d'emplacement lors de l'utilisation du port standard.
HTTP par défaut est le port TCP 80. Www.example.com:80
Https utilise par défaut le port TCP 443 Www.example.com:443
Même si le domaine et l'ip sont identiques, les ports ne le sont pas. Du point de vue du navigateur, le navigateur communique avec différents sites.
MISE À JOUR
Le réseau ne l'affecte pas autant que le S dans le https. C'est aussi un URI différent.
Laissant de côté le fait que la spécification est assez claire que différentes URL doivent être traitées comme des ressources différentes, ne pensez-vous pas que quelqu'un aurait déjà remarqué et exploité cela si ce n'était pas le cas? Après tous les problèmes exposés par les cookies (et traités par le drapeau "sécurisé") sont connus depuis environ 20 ans ou plus.
Le navigateur doit donc récupérer les deux URL. Il est concevable qu'un cache puisse conserver une seule copie d'un fichier téléchargé à partir de différentes sources mais accessible via différentes clés - ou que cette déduplication puisse se produire plus profondément dans le système de fichiers (déduplication). Mais cela ne se produirait que après le cache (ou le système de fichiers) avait déterminé que les fichiers étaient les mêmes.
Oui, ce sont des origines différentes. Bien qu'il soit très probable qu'ils servent le même contenu, ils peuvent techniquement servir un contenu entièrement différent. Pour cette raison, le navigateur n'est pas autorisé à les traiter comme la même ressource.
Du point de vue du serveur, la même URL (par exemple, www.test.com) sur différents protocoles (par exemple, HTTP vs HTTPS) peut utiliser une source de fichier différente. Ainsi, une URL avec TLS peut générer un site Web complètement différent de l'URL sans TLS. Cela seul me fait penser que les navigateurs n'utiliseront pas le même cache pour les deux fichiers.