Varier: en-tête de réponse d'origine et exploitation CORS
Récemment, PortSwigger (les gars derrière Burp Suite) a publié un article de blog sur les risques de sécurité associés aux erreurs de configuration de CORS.
http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
En résumé, le blog parle de moyens non sécurisés d'activer CORS qui peuvent permettre à des sites Web malveillants de lire des données à partir d'un site cible. Vers la fin, le blog parle d'un mécanisme de prévention impliquant le Vary: Origin entête:
Si vous jetez un œil à la section `` Considérations d'implémentation '' dans la spécification CORS, vous remarquerez qu'elle indique aux développeurs de spécifier l'en-tête HTTP `` Vary: Origin '' chaque fois que les en-têtes Access-Control-Allow-Origin sont générés dynamiquement.
J'ai du mal à comprendre comment exactement l'en-tête Vary aide à empêcher l'exploitation de CORS (XSS en utilisant l'empoisonnement du cache) dans un scénario où le Access-Control-Allow-Origin l'en-tête est généré dynamiquement (contrôlé par le client).
Il est important d'inclure le Vary: Origin en-tête pour empêcher la mise en cache. L'en-tête indique que la réponse dépend en quelque sorte de l'origine et ne doit donc pas être servie à partir du cache pour toute autre origine. Si l'en-tête est manquant, des attaques d'empoisonnement du cache peuvent être possibles, comme expliqué dans l'article par l'exemple de XSS via un en-tête personnalisé reflété. Un en-tête Vary manquant ne crée pas à lui seul une vulnérabilité.