Salut à tous,
Comme nombre d’entre vous, je fais à mes heures perdues un peu de veille informatique.
C’est toujours utile de rester en mouvement dans un monde technologique en perpétuel mouvement.
J’ai, pas plus tard qu’hier, découvert un nouveau type d’attaque.
Je me suis dit que c’était peut-être l’occasion de vous dire que je suis toujours là, bien vivant, mais un peu moins actif aussi …
Cache & Optimisation
Nombreux sont les serveurs Web qui utilisent ce que l’on appelle du “cache“.
Le cache consiste à dire qu’un fichier ne bougera pas, qu’il n’est pas nécessaire de faire un quelconque traitement dessus, et donc, que si quelqu’un souhaite accéder à ce fichier, on peut lui envoyer telle quelle (sans vérifier si celui-ci a changé depuis la dernière consultation).
Cela permet à un serveur de ne pas travailler lorsque cela n’est pas nécessaire.
Le plus souvent, on met en cache les fichiers css, javascript, mp3, mp4 …
Bref, les fichiers volumineux ou non, qui ne changent pas tous les jours.
Aussi, un serveur peut être configuré pour qu’automatiquement, lorsqu’on lui demande d’accéder à tel type de fichier, le fichier en question, reste en cache durant x secondes / minutes / heures / jours …
Ergonomie et confort
Pour éviter de perdre un client sur un lien erroné, comme cela arrive souvent, de nombreux sites vont afficher une page par défaut…
Cela peut être dans le cas d’un vieux lien, d’un mauvais copier-coller, …
Bref les raisons sont multiples …
Par exemple si je souhaite me rendre sur une url du type :
https://site.com/home/myaccount/tutututututututut
Le lien fonctionnera probablement, mais m’affichera en réalité la page :
https://site.com/home/myaccount/
Cette page affichera peut-être votre nom, votre prénom, votre email … éventuellement un identifiant unique dans le code source permettant de vous authentifier …
Concept de l’attaque “Web Cache Deception“
Cette attaque exploite donc à la fois un aspect “optimisation par le cache”, et un aspect le “confort d’utilisation”.
En imaginant, toujours pour reprendre notre précédent exemple, qu’un utilisateur A se rende sur le lien suivant :
https://site.com/home/myaccount/fichier-qui-n-existe-pas.css
En imaginant que le site, malgré l’absence du fichier “fichier-qui-n-existe-pas.css“, affiche quand même la page : https://site.com/home/myaccount/
Alors, si le serveur est configuré pour mettre en cache tous les fichiers “.css”
Même si le fichier n’existe pas, le contenu de “https://site.com/home/myaccount/” qui s’affichera, sera considéré comme le contenu du fichier “fichier-qui-n-existe-pas.css“.
Le lien
https://site.com/home/myaccount/fichier-qui-n-existe-pas.css
Sera donc créé avec le contenu de la page “https://site.com/home/myaccount/“
Si un utilisateur B tente à son tour d’accéder au fichier “fichier-qui-n-existe-pas.css” celui-ci pourra consulter la page “https://site.com/home/myaccount/” de l’utilisateur A
Conclusion
Pour se protéger de ce genre de vulnérabilité, il vaut mieux définir soit même les fichiers à mettre en cache, c’est plus long, mais plus précis, qu’un traitement automatique qui génère à la volée les fichiers à mettre en cache.