Qu'est-ce que l'en-tête HTTP «Upgrade-Insecure-Requests»?

221

J'ai fait une demande POST à un site HTTP (non-HTTPS), j'ai inspecté la demande dans les outils de développement de Chrome et j'ai constaté qu'il ajoutait son propre en-tête avant de l'envoyer au serveur:

Upgrade-Insecure-Requests: 1

Après avoir fait une recherche Upgrade-Insecure-Requests, je ne peux trouver que des informations sur le serveur qui envoie cet en- tête:

Content-Security-Policy: upgrade-insecure-requests

Cela semble lié, mais toujours très différent puisque dans mon cas, le CLIENT envoie l'en-tête dans la demande , alors que toutes les informations que j'ai trouvées concernent le SERVEUR envoyant l'en-tête associé dans une réponse .

Alors pourquoi Chrome (44.0.2403.130 m) ajoute-t-il Upgrade-Insecure-Requestsà ma demande et que fait-il?

Mise à jour 2016-08-24:

Cet en-tête a depuis été ajouté en tant que recommandation candidate du W3C et est maintenant officiellement reconnu.

Pour ceux qui viennent de tomber sur cette question et sont confus, l' excellente réponse de Simon East l'explique bien.

L'en- Upgrade-Insecure-Requests: 1tête était HTTPS: 1 dans le précédent projet de travail du W3C et a été renommé discrètement par Chrome avant que le changement ne soit officiellement accepté.

(Cette question a été posée lors de cette transition alors qu'il n'y avait pas de documentation officielle sur cet en-tête et Chrome était le seul navigateur à avoir envoyé cet en-tête.)

— user193130
source

Firefox le fait aussi.

— dakab

Doit être nouveau; Je fais d'abord du développement sur Firefox et cet en-tête n'a certainement pas été envoyé par Firefox l'année dernière.

— user193130

Réponses:

274

Réponse courte: elle est étroitement liée à l'en- Content-Security-Policy: upgrade-insecure-requeststête de réponse, indiquant que le navigateur la prend en charge (et en fait la préfère).

Il m'a fallu 30 minutes de recherche sur Google, mais je l'ai finalement trouvé enfoui dans la spécification W3.

La confusion vient du fait que l'en-tête de la spécification était HTTPS: 1, et c'est ainsi que Chromium l'a implémenté, mais après cela, de nombreux sites Web mal codés (en particulier WordPress et WooCommerce) ont été cassés, l'équipe Chromium s'est excusée:

"Je m'excuse pour la rupture; j'ai apparemment sous-estimé l'impact basé sur les commentaires lors du développement et de la bêta."
- Mike West, dans Chrome Issue 501842

Leur correctif consistait à le renommer Upgrade-Insecure-Requests: 1et la spécification a depuis été mise à jour pour correspondre.

Quoi qu'il en soit, voici l'explication de la spécification W3 (telle qu'elle apparaissait à l'époque) ...

Le HTTPSchamp d'en-tête de demande HTTP envoie un signal au serveur exprimant la préférence du client pour une réponse chiffrée et authentifiée, et qu'il peut gérer avec succès la directive de demande de mise à niveau non sécurisée afin de rendre cette préférence aussi transparente que possible à fournir.

...

Lorsqu'un serveur rencontre cette préférence dans les en-têtes d'une demande HTTP, il DEVRAIT rediriger l'utilisateur vers une représentation potentiellement sécurisée de la ressource demandée.

Lorsqu'un serveur rencontre cette préférence dans les en-têtes d'une demande HTTPS, il DEVRAIT inclure un en- Strict-Transport-Securitytête dans la réponse si l'hôte de la demande est HSTS-safe ou HSTS-safe conditionnellement [RFC6797].

— Simon East
source

Je n'arrive pas à le comprendre. Je suis a.comet vous redirige vers b.com, tout en fournissant cet en-tête b.comet en envoyant des informations. Si vous n'êtes pas sous un canal sécurisé b.com, une attaque par reniflement peut déjà se produire, car j'ai envoyé des données à b.comcôté de ma demande. Pouvez-vous nous guider vers un scénario simple montrant comment il rend les connexions plus sécurisées pour les utilisateurs?

— Saeed Neamati

@SaeedNeamati Dans une perspective très stricte, cela ne rend rien de plus sûr. Si vous avez des exigences de sécurité normales, vous devez d'abord vous assurer de vous connecter via HTTPS et ne pas vous y fier. Cela étant dit, je qualifierais cela dans le contexte de l'idée de « confiance de la première utilisation », ce qui fait de l' aide passive.

— TNE

Je vois cela plus comme le désir du client que comme un outil de sécurité. C'est comme un en-tête "DNT", le serveur pourrait l'ignorer, mais il exprime néanmoins la volonté du client.

— DUzun

Ma réponse pourrait en fait être améliorée pour expliquer correctement comment le client et le serveur négocient cela. N'hésitez pas à suggérer des améliorations si vous le souhaitez.

— Simon East

Cela explique le tout:

La directive HTTP Content-Security-Policy (CSP) upgrade-insecure-requests demande aux agents utilisateurs de traiter toutes les URL non sécurisées d'un site (celles qui sont servies via HTTP) comme si elles avaient été remplacées par des URL sécurisées (celles servies via HTTPS). Cette directive est destinée aux sites Web contenant un grand nombre d'URL héritées non sécurisées qui doivent être réécrites.

La directive upgrade-insecure-requests est évaluée avant block-all-mixed-content et si elle est définie, ce dernier est effectivement un no-op. Il est recommandé de définir une directive ou l'autre, mais pas les deux.

La directive sur les demandes de mise à niveau non sécurisée ne garantira pas que les utilisateurs visitant votre site via des liens sur des sites tiers seront mis à niveau vers HTTPS pour la navigation de niveau supérieur et ne remplacent donc pas l'en-tête Strict-Transport-Security (HSTS), qui doit toujours être défini avec un âge maximal approprié pour garantir que les utilisateurs ne sont pas soumis à des attaques de suppression SSL.

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

— Basil Musa
source