Pourquoi non-cache et no-store doivent-ils être utilisés dans la réponse HTTP?
On me dit d'empêcher les fuites d'informations utilisateur, seul le "no-cache" en réponse ne suffit pas. "no-store" est également nécessaire.
Cache-Control: no-cache, no-store
Après avoir lu cette spécification http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , je ne comprends toujours pas pourquoi.
Ma compréhension actuelle est que ce n'est que pour le serveur de cache intermédiaire. Même si "no-cache" est répondu, le serveur de cache intermédiaire peut toujours enregistrer le contenu sur un stockage non volatile. Le serveur de cache intermédiaire décidera d'utiliser ou non le contenu enregistré pour la requête suivante. Cependant, si "no-store" est dans la réponse, le serveur de cache intermédiaire n'est pas censé stocker le contenu. Donc, c'est plus sûr.
Existe-t-il une autre raison pour laquelle nous avons besoin de "no-cache" et de "no-store"?
Je dois préciser que no-cache ne signifie pas ne pas mettre en cache. En fait, cela signifie "revalider avec le serveur" avant d'utiliser toute réponse en cache que vous pourriez avoir, à chaque demande.
must-revalidate, d'autre part, n'a besoin de revalider que lorsque la ressource est considérée comme périmée.
Si le serveur dit que la ressource est toujours valide, le cache peut répondre avec sa représentation, évitant ainsi au serveur de renvoyer la totalité de la ressource.
no-store est en réalité la directive complète ne pas mettre en cache et est destiné à empêcher le stockage de la représentation sous quelque forme de cache que ce soit.
Je dis que ce soit, mais notez ceci dans la spécification HTTP RFC 2616:
Les tampons d’historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal
Mais ceci est omis de la nouvelle spécification HTTP RFC 7234 dans le but potentiellement de rendre no-store plus fort, voir:
Dans certaines circonstances, IE6 mettra toujours en cache les fichiers même lorsque Cache-Control: no-cache se trouve dans les en-têtes de réponse.
Les états du W3C de no-cache :
Si la directive no-cache ne le fait pas spécifiez un nom de champ, puis un cache NE DOIT PAS utiliser la réponse pour satisfaire un demande ultérieure sans succès revalidation avec le serveur d'origine.
Dans mon application, si vous avez visité une page avec l'en-tête no-cache, que vous vous êtes déconnecté puis réactivé dans votre navigateur, IE6 extrairait toujours la page du cache (sans nouvelle demande/validation au serveur). L'ajout dans l'en-tête no-store l'a arrêté. Mais si vous prenez le W3C à leur mot, il n’ya aucun moyen de contrôler ce comportement:
Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal.
Les différences générales entre l'historique du navigateur et la mise en cache HTTP normale sont décrites dans une sous-section spécifique de la spécification .
A partir de la spécification HTTP 1.1 :
no-store:
La directive no-store a pour but d'empêcher la divulgation ou la rétention par inadvertance d'informations sensibles (par exemple, sur des bandes de sauvegarde). La directive no-store s’applique à l’ensemble du message et PEUT être envoyée dans une réponse ou une demande. Si elle est envoyée dans une demande, un cache NE DOIT PAS stocker aucune partie de cette demande ni aucune réponse à celle-ci. S'il est envoyé dans une réponse, un cache NE DOIT PAS stocker aucune partie de cette réponse ni de la demande qui l'a provoquée. Cette directive s'applique aux caches non partagés et partagés. "NE DOIT PAS stocker" dans ce contexte signifie que le cache NE DOIT PAS stocker intentionnellement les informations dans une mémoire non volatile, et DOIT faire tout son possible pour supprimer les informations de la mémoire volatile le plus rapidement possible après les avoir transférées . Même lorsque cette directive est associée à une réponse, les utilisateurs peuvent stocker explicitement une telle réponse en dehors du système de mise en cache (par exemple, avec une boîte de dialogue "Enregistrer sous"). Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal . Le but de cette directive est de répondre aux exigences énoncées par certains utilisateurs et auteurs de services qui s’inquiètent de la divulgation accidentelle d’informations via des accès imprévus aux structures de données en cache. Bien que l'utilisation de cette directive puisse améliorer la confidentialité dans certains cas, nous vous avertissons qu'il ne s'agit en aucun cas d'un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis pourraient ne pas reconnaître ou obéir à cette directive, et les réseaux de communication pourraient être vulnérables à une écoute indiscrète.
Si vous souhaitez empêcher toute mise en cache (par exemple, forcer un rechargement lorsque vous utilisez le bouton Précédent), vous avez besoin des éléments suivants:
no-cache pour IE
no-store pour Firefox
Voici mes informations à ce sujet ici:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
no-store ne devrait pas être nécessaire dans des situations normales et peut nuire à la vitesse et à la facilité d'utilisation. Il est destiné à être utilisé lorsque la réponse HTTP contient des informations si sensibles qu’elles ne doivent jamais être écrites dans un cache de disque, quels que soient les effets négatifs que cela entraîne pour l’utilisateur.
Comment ça marche:
Normalement, même si un agent utilisateur tel qu'un navigateur détermine qu'une réponse ne doit pas être mise en cache, il peut toujours la stocker dans le cache de disque pour des raisons internes à l'agent d'utilisateur. Cette version peut être utilisée pour des fonctionnalités telles que "Afficher la source", "Précédent", "Informations de page", etc., lorsque l'utilisateur n'a pas forcément demandé de nouveau la page, mais que le navigateur ne la considère pas comme une nouvelle vue de page. et il serait judicieux de servir la même version que celle actuellement visualisée par l'utilisateur.
L'utilisation de
no-storeempêchera le stockage de cette réponse, mais cela pourrait affecter la capacité du navigateur à donner les "sources", "Retour", "Informations de page", etc. sans faire une nouvelle demande séparée pour le serveur, ce qui n'est pas souhaitable. En d'autres termes, l'utilisateur peut essayer de visualiser la source et si le navigateur ne l'a pas gardée en mémoire, on lui dira que ce n'est pas possible ou que cela provoquera une nouvelle demande du serveur. Par conséquent,no-storene doit être utilisé que lorsque l'expérience utilisateur gênée par ces fonctionnalités ne fonctionne pas correctement ou rapidement est compensée par l'importance de garantir que le contenu n'est pas stocké dans le cache.
Ma compréhension actuelle est que ce n'est que pour le serveur de cache intermédiaire. Même si "no-cache" est répondu, le serveur de cache intermédiaire peut toujours enregistrer le contenu sur un stockage non volatile.
Ceci est une erreur. Les serveurs de cache intermédiaires compatibles avec HTTP 1.1 obéiront aux instructions no-cache et must-revalidate, assurant ainsi que le contenu n'est pas mis en cache. En utilisant ces instructions, vous vous assurez que la réponse n'est pas mise en cache par un cache intermédiaire et que toutes les demandes suivantes sont renvoyées au serveur Origin.
Si le serveur de cache intermédiaire ne prend pas en charge HTTP 1.1, vous devrez alors utiliser Pragma: no-cache et espérer que tout ira pour le mieux. Notez que s'il ne supporte pas HTTP 1.1, alors no-store n'a de toute façon pas d'importance.
Si un système de mise en cache implémente correctement le no-store, vous n'avez pas besoin de no-cache. Mais pas tous. De plus, certains navigateurs implémentent no-cache comme s'il s'agissait de no-store. Ainsi, bien que cela ne soit pas strictement requis, il est probablement plus sûr d’inclure les deux.
Pour chrome, no-cache est utilisé pour recharger la page lors d'une nouvelle visite, mais il la cache quand même si vous revenez dans l'historique (bouton Précédent). Pour recharger la page pour l'historique également, utilisez no-store. IE a besoin de revalider pour fonctionner en toutes circonstances.
Donc, juste pour être sûr d'éviter tous les bugs et les fausses interprétations que j'utilise toujours
Cache-Control: no-store, no-cache, must-revalidate
si je veux être sûr que ça recharge.
Notez qu'Internet Explorer de la version 5 à la version 8 génère une erreur lorsque vous essayez de télécharger un fichier servi via https et que le serveur envoie les en-têtes Cache-Control: no-cache ou Pragma: no-cache.
Voir http://support.Microsoft.com/kb/812935/en-us
L'utilisation de Cache-Control: no-store et Pragma: private semble être la chose la plus proche qui fonctionne toujours.
À l'origine, nous utilisions no-cache il y a de nombreuses années et nous avons rencontré des problèmes de contenu obsolète avec certains navigateurs ... Ne vous souvenez pas des détails, malheureusement.
Nous avions depuis décidé de JUSTER l’utilisation de no-store. Nous n'avons jamais regardé en arrière ou eu un seul problème avec le contenu obsolète par un navigateur ou des intermédiaires depuis.
Cet espace est certainement dominé par la réalité des implémentations par rapport à ce qui est écrit dans différents RFC. Beaucoup de mandataires en particulier ont tendance à penser qu'ils "améliorent la performance" en remplaçant la politique qu'ils sont censés suivre par la leur.
Pour aggraver les choses, dans certaines situations, no-cache ne peut pas être utilisé, mais no-store peut:
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/
OWASP en parle:
Quelle est la différence entre les directives de contrôle du cache: no-cache et no-store?
La directive no-cache dans une réponse indique que la réponse ne doit pas être utilisée pour répondre à une demande ultérieure, c.-à-d. Que le cache ne doit pas afficher une réponse dont cette directive est définie dans l'en-tête mais doit laisser le serveur répondre à la demande. La directive no-cache peut inclure certains noms de champs; Dans ce cas, la réponse peut être affichée à partir du cache, à l'exception des noms de champs spécifiés qui doivent être fournis par le serveur. La directive no-store s’applique à l’ensemble du message et indique que le cache ne doit stocker aucune partie de la réponse ni aucune demande qui l’a demandée.
Suis-je totalement en sécurité avec ces directives?
Non, mais généralement, utilisez à la fois Cache-Control: no-cache, no-store et Pragma: no-cache, en plus de Expires: 0 (ou une date GMT suffisamment rétroactive, telle que l’époque UNIX). Les types de contenu non html tels que pdf, documents Word, feuilles de calcul Excel, etc. sont souvent mis en cache même lorsque les directives de contrôle du cache ci-dessus sont définies (bien que cela varie selon la version et l'utilisation supplémentaire de must-revalidate, pre-check = 0, post-check = 0, max-age = 0 et s-maxage = 0 peuvent dans certains cas entraîner au moins la suppression de fichiers à la fermeture du navigateur, dans certains cas en raison de problèmes de navigateur et d'implémentations HTTP). En outre, la fonctionnalité de saisie semi-automatique permet à un navigateur de mettre en cache tout type d'utilisateur saisi dans un champ de saisie d'un formulaire. Pour vérifier cela, la balise de formulaire ou les balises d'entrée individuelles doivent inclure l'attribut 'Autocomplete = "Off"'. Cependant, il convient de noter que cet attribut est non standard (bien qu'il soit pris en charge par les principaux navigateurs), il rompra donc la validation XHTML.
Source ici .