La compression HTTP est-elle sûre?
L'attaque CRIME nous a appris que l'utilisation de la compression peut mettre en danger la confidentialité. En particulier, il est dangereux de concaténer des données fournies par l'attaquant avec des données secrètes sensibles, puis de compresser et de crypter la concaténation; chaque fois que nous constatons que cela se produit, à n'importe quelle couche de la pile système, nous devons nous méfier du potentiel d'attaques de type CRIME.
Maintenant, l'attaque CRIME, du moins telle qu'elle a été décrite publiquement jusqu'à présent, est une attaque contre la compression TLS. Contexte: TLS comprend un mécanisme de compression intégré, qui se produit au niveau TLS (toute la connexion est compressée). Ainsi, nous avons une situation où les données fournies par l'attaquant (par exemple, le corps d'une POST) sont mélangées avec des secrets (par exemple, les cookies dans les en-têtes HTTP), ce qui a permis au CRIME attaque.
Cependant, il existe également d'autres couches de la pile système qui peuvent utiliser la compression. Je pense notamment à compression HTTP . Le protocole HTTP a un support intégré pour compresser toutes les ressources que vous téléchargez via HTTP. Lorsque la compression HTTP est activée, la compression est appliquée au corps de la réponse (mais pas aux en-têtes). La compression HTTP ne sera activée que si le navigateur et le serveur le prennent en charge, mais la plupart des navigateurs et de nombreux serveurs le font, car cela améliore les performances . Notez que la compression HTTP est un mécanisme différent de la compression TLS; La compression HTTP est négociée à un niveau supérieur de la pile et ne s'applique qu'au corps de la réponse. Cependant, la compression HTTP peut être appliquée aux données téléchargées via une connexion SSL/TLS, c'est-à-dire aux ressources téléchargées via HTTPS.
Ma question: la compression HTTP est-elle sûre à utiliser, sur les ressources HTTPS? Dois-je faire quelque chose de spécial pour désactiver la compression HTTP des ressources accessibles via HTTPS? Ou, si la compression HTTP est en quelque sorte sûre, pourquoi est-elle sûre?
Cela me semble risqué. La compression HTTP est correcte pour les ressources statiques, mais pour certaines ressources dynamiques servies via SSL, il semble que la compression HTTP puisse être dangereuse. Il me semble que la compression HTTP peut, dans certaines circonstances, permettre des attaques de type CRIME.
Considérez une application Web qui a une page dynamique avec les caractéristiques suivantes:
Il est servi sur HTTPS.
La compression HTTP est prise en charge par le serveur (cette page sera envoyée au navigateur sous forme compressée, si le navigateur prend en charge la compression HTTP).
La page contient un jeton CSRF quelque part. Le jeton CSRF est fixé pour la durée de vie de la session (par exemple). C'est le secret que l'attaque tentera d'apprendre.
La page contient du contenu dynamique qui peut être spécifié par l'utilisateur. Pour simplifier, supposons qu'il y ait un paramètre d'URL qui est répercuté directement dans la page (peut-être avec un échappement HTML appliqué pour empêcher XSS, mais c'est bien et ne dissuadera pas l'attaque décrite).
Ensuite, je pense que les attaques de style CRIME pourraient permettre à un attaquant d'apprendre le jeton CSRF et de monter des attaques CSRF sur le site Web.
Laissez-moi vous donner un exemple. Supposons que l'application Web cible soit un site Web bancaire sur www.bank.com, et la page vulnérable est https://www.bank.com/buggypage.html. Supposons que la banque s'assure que les informations bancaires ne sont accessibles que par SSL (https). Et supposons que si le navigateur visite https://www.bank.com/buggypage.html?name=D.W., le serveur répondra par un document HTML ressemblant vaguement à ceci:
<html>...<body>
Hi, D.W.! Pleasure to see you again. Some actions you can take:
<a href="/closeacct&csrftoken=29238091">close my account</a>,
<a href="/viewbalance&csrftoken=...">view my balance</a>, ...
</body></html>
Supposons que vous naviguez sur le Web via une connexion Wifi ouverte, afin qu'un attaquant puisse espionner tout votre trafic réseau. Supposons que vous êtes actuellement connecté à votre banque, de sorte que votre navigateur a une session ouverte avec le site Web de votre banque, mais que vous n'effectuez aucune opération bancaire via la connexion Wifi ouverte. Supposons en outre que l'attaquant puisse vous inciter à visiter son site Web http://www.evil.com/ (par exemple, peut-être en vous attaquant par un homme du milieu et en vous redirigeant lorsque vous essayez de visiter un autre site http).
Ensuite, lorsque votre navigateur visite http://www.evil.com/, cette page peut déclencher des demandes interdomaines vers le site Web de votre banque, dans le but d'apprendre le jeton CSRF secret. Notez que Javascript est autorisé à effectuer des demandes interdomaines. La stratégie de même origine l'empêche de voir la réponse à une demande interdomaine. Néanmoins, puisque l'attaquant peut écouter le trafic réseau, l'attaquant peut observer la longueur de tous les paquets chiffrés et ainsi déduire quelque chose de la longueur des ressources qui sont téléchargées via la connexion SSL à votre banque.
En particulier, le programme malveillant http://www.evil.com/ la page peut déclencher une demande à https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1 et regardez dans quelle mesure la page HTML résultante se comprime (en écoutant les paquets et en regardant la longueur du paquet SSL de la banque). Ensuite, il peut déclencher une demande à https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2 et voyez à quel point la réponse se comprime. Et ainsi de suite, pour chaque possibilité pour le premier chiffre du jeton CSRF. L'un d'eux devrait être un peu mieux compressé que les autres: celui où le chiffre du paramètre URL correspond au jeton CSRF de la page. Cela permet à l'attaquant d'apprendre le premier chiffre du jeton CSRF.
De cette façon, il apparaît que l'attaquant peut apprendre chaque chiffre du jeton CSRF, en les récupérant chiffre par chiffre, jusqu'à ce que l'attaquant apprenne l'intégralité du jeton CSRF. Ensuite, une fois que l'attaquant connaît le jeton CSRF, il peut avoir sa page malveillante sur www.evil.com déclenche une demande interdomaine qui contient le jeton CSRF approprié - en réussissant à vaincre les protections CSRF de la banque.
Il semble que cela puisse permettre à un attaquant de monter une attaque CSRF réussie sur des applications Web, lorsque les conditions ci-dessus s'appliquent, si la compression HTTP est activée. L'attaque est possible car nous mélangeons des secrets avec des données contrôlées par l'attaquant dans la même charge utile, puis compressons et chiffrons cette charge utile.
S'il y a d'autres secrets qui sont stockés dans du HTML dynamique, je pourrais imaginer que des attaques similaires pourraient devenir possibles pour apprendre ces secrets. Ce n'est qu'un exemple du type d'attaque auquel je pense. Il me semble donc que l'utilisation de la compression HTTP sur des pages dynamiques accessibles via HTTPS est un peu risquée. Il peut y avoir de bonnes raisons de désactiver la compression HTTP sur toutes les ressources servies via HTTPS, à l'exception des pages/ressources statiques (par exemple, CSS, Javascript).
La compression, en général, modifie la longueur de ce qui est compressé (c'est exactement pourquoi nous compressons). compression sans perte modifie la longueur en fonction des données elles-mêmes (tandis que la compression avec perte peut atteindre un taux de compression fixe, par exemple un fichier MP3 à un strict 128 kbit/s). La longueur des données est ce qui fuit par le cryptage, c'est pourquoi nous nous y intéressons.
De manière très générique, une fuite de longueur peut être fatale, même en présence d'un attaquant passif uniquement; c'est une sorte de analyse du trafic . Un exemple est tiré de la Première Guerre mondiale, où les cryptographes français pouvaient prédire l'importance d'un message en fonction de la longueur de l'en-tête (crypté): un message important a été envoyé au colonel ( Oberst ) alors que les messages moins importants étaient étiquetés pour un lieutenant ( Oberleutnant , un terme beaucoup plus long).
La compression ne fait qu'aggraver les fuites de longueur, car elle vous empêche de corriger les fuites de longueur en normalisant la longueur des messages.
Lorsque l'attaquant peut ajouter ses propres données dans les segments compressés, il amplifie la fuite de longueur, qui peut devenir un vecteur d'attaque pratique pour des données cibles arbitraires, comme le montre l'attaque CRIME. Cependant, je soutiens que le problème était déjà là. Dans cette vue, la compression au niveau HTTP n'est pas un nouveau risque; il s'agit plutôt d'un facteur aggravant d'un risque préexistant. Laisser l'attaquant ajouter certaines de ses propres données dans le flux crypté est encore un autre facteur aggravant, et ces facteurs s'additionnent.
Je parie que vous n'êtes pas le premier à avoir cette idée. Non seulement beaucoup de gens (moi y compris) y ont réfléchi au cours des 10 derniers jours, mais si vous essayez d'accéder à cette URL:
http://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa
vous obtenez alors une erreur 404 de Google, qui contient le mot "sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa". Hé, c'est l'attaquant qui a choisi les données réfléchies, ça pourrait être amusant! Essayons donc à nouveau avec une URL HTTPS:
https://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa
et puis, non 404, pas de plaisir, vous êtes redirigé sans cérémonie vers la page d'accueil de Google. Cela me fait penser que certaines personnes chez Google y ont déjà pensé aussi et ont désactivé de manière proactive le bit de réflexion lors de l'utilisation de SSL (car lors de l'utilisation de SSL, vous obtenez les cloches et sifflets Google+, donc des données potentiellement dangereuses).