Qu'est-ce que L'en-tête HTTP" Upgrade-Insecure-Requests"?
j'ai fait une requête POST à un site HTTP (non-HTTPS), inspecté la requête dans les outils de développement de Chrome, et constaté qu'il a ajouté son propre en-tête avant de l'envoyer au serveur:
Upgrade-Insecure-Requests: 1
après avoir fait une recherche sur Upgrade-Insecure-Requests , Je ne peux trouver information à propos du serveur d'envoi ce en-tête:
Content-Security-Policy: upgrade-insecure-requests
cela semble lié, mais encore très différent puisque dans mon cas, le Le CLIENT envoie l'en-tête de la Request , alors que toutes les informations que j'ai trouvées concernent le serveur qui envoie l'en-tête correspondant dans une Response .
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 recommandation du candidat du W3C et est maintenant officiellement reconnu.
pour ceux qui viennent de rencontrer cette question et sont confus, le excellente réponse par Simon East l'explique bien.
l'en-tête Upgrade-Insecure-Requests: 1 était HTTPS: 1 dans le projet de travail précédent du W3C et a été renommé tranquillement par Chrome avant le changement fut officiellement accepté.
(cette question a été posée lors de cette transition alors qu'il n'y avait aucune documentation officielle sur cet en-tête et que Chrome était le seul navigateur à avoir envoyé cet en-tête.)
2 réponses
courte réponse: elle est étroitement liée à l'en-tête de réponse Content-Security-Policy: upgrade-insecure-requests , indiquant que le navigateur le supporte (et le préfère en fait).
il m'a fallu 30 minutes de Googling, mais je l'ai finalement trouvé enterré dans le W3 spec.
la confusion vient parce que l'en-tête dans le spec était HTTPS: 1 , et C'est comment Chrome l'a mis en œuvre, mais après cette cassé beaucoup de sites Web qui ont été mal codé (notamment WordPress et WooCommerce) l'équipe Chromium s'est excusée:
" Je m'excuse pour le bris; j'ai apparemment sous-estimé l'impact basé sur les retours lors de dev et beta."
- Mike West, dans Chrome Question 501842
leur correctif était de le renommer en Upgrade-Insecure-Requests: 1 , et le spec a depuis été mis à jour pour correspondre.
Quoi qu'il en soit, voici l'explication de la spécification W3 (telle qu'elle apparaissait à l'époque) ...
le champ D'en-tête de la requête HTTP
HTTPSenvoie 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 mise à jour-unsecure-requests directive afin de faire cette préférence comme transparente que possible pour fournir....
Lorsqu'un serveur rencontre cette préférence dans les en-têtes D'une requête HTTP, il doit 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 requête HTTPS, il doit inclure un en-tête
Strict-Transport-Securitydans la réponse si l'hôte de la requête est HSTS-safe ou conditionnellement HSTS-safe [RFC6797].
cela explique le tout:
le contenu HTTP-sécurité-politique (CSP) - mise à niveau-non-sécurisation-requêtes la directive indique aux agents utilisateurs de traiter toutes les URLs non sécurisées d'un site (ceux servis sur HTTP) comme s'ils avaient été remplacés par des URLs (ceux servis sur HTTPS). Cette directive est destinée au web sites avec un grand nombre d'URLs d'héritage non sécurisées qui doivent être réécrire.
le la directive upgrade-insecure-requests est évaluée avant bloc-tous-mixte-contenu et si elle est définie, cette dernière est effectivement un non-op. Il est recommandé de définir une directive ou l'autre, mais pas les deux.
la directive upgrade-insecure-requests ne garantit pas que les utilisateurs visiter votre site via des liens sur des sites tiers sera mis à jour à HTTPS pour la navigation de haut niveau et ne remplace donc pas le L'en-tête transport-sécurité (HSTS) Strict, qui devrait toujours être ensemble avec un âge maximal approprié pour s'assurer que les utilisateurs ne sont pas soumis à SSL décapage des attaques.