En supposant que le serveur effectue des actions basées sur une condition spécifique, analysons une situation où le serveur réalise des calculs en fonction du résultat de cette condition et transmet ensuite la réponse à l’utilisateur. Dans les deux cas, que les calculs soient effectués ou non, le serveur renvoie une réponse à l’utilisateur. Il est à noter que lorsque le serveur effectue des calculs, il utilise une certaine quantité de ressources, ce qui conduit à un allongement du temps de réponse du serveur. Habituellement, ces différences de temps de réponse sont si minimes qu’elles sont indétectables pour l’utilisateur final. Cependant, la révélation de ces différences subtiles dans le temps de réponse peut conduire à une fuite involontaire de données.
Considérons maintenant un exemple pratique de cette situation, basé sur le processus de connexion à une application. Supposons que le login donné soit correct, mais que le mot de passe soit incorrect : dans ce cas, le serveur peut décider d’effectuer des calculs, par exemple la vérification du mot de passe. Si le serveur procède à ces calculs, cela peut nécessiter des ressources supplémentaires et entraîner un temps de réponse plus long par rapport au cas où les calculs ne sont pas effectués. Bien que les différences de temps de réponse soient généralement faibles, elles sont présentes et peuvent être mesurées par un attaquant.
Le même processus, mais cette fois-si le login est également incorrect :
Dans le cas de différences si subtiles dans le temps de réponse, un attaquant peut tenter d’exploiter cette information pour inférer la validité du login. Par exemple, un attaquant peut effectuer une attaque de type timing attack en analysant le temps que le serveur met à répondre aux requêtes avec différents logins. En comparant les temps de réponse, l’attaquant peut déduire quelle requête a pris plus de temps, ce qui suggère que le login était correct. La révélation du login de l’utilisateur permet aux attaquants d’effectuer une attaque par force brute pour deviner le mot de passe. Dans certains cas, cela peut également révéler des informations sensibles, notamment lorsque le login est une adresse e-mail associée à une personne spécifique et que l’application testée est un portail avec un contenu controversé.
Tester avec Burp Suite – Request Timer
Lors de la recherche de ce type de vulnérabilité, le plugin Burp appelé Request Timer sera utile. Ce plugin nous permettra d’examiner le temps de réponse du serveur pour les requêtes que nous spécifions.
La première étape consistera à intercepter la requête responsable de la connexion de l’utilisateur et à l’envoyer au module Intruder :
Ensuite, nous changeons le mot de passe en une longue chaîne de caractères, afin d’augmenter la charge du serveur lors de la génération du hash du mot de passe. Nous indiquons l’emplacement du nom d’utilisateur. Pour l’application testée, il est également nécessaire d’ajouter un en-tête « X-Forwarded-For » et de lui attribuer une adresse IP aléatoire pour contourner le blocage des tentatives de connexion multiples à partir de la même adresse IP. Par conséquent, nous devons changer le type d’attaque en « Pitchfork ».
Nous ajoutons une liste de logins à vérifier :
Dans le plugin Request Timer, nous définissons qu’il doit écouter le module Intruder :
Après le démarrage du test, les requêtes générées et le temps de réponse apparaîtront dans l’onglet. Comme on peut le voir, pour le login correct, le temps de réponse est beaucoup plus long. De cette manière, nous avons démontré que l’application est vulnérable à l’énumération des logins des utilisateurs par l’analyse du temps de réponse du serveur.
Que faire, comment vivre ?
Une des solutions à ce type de problème est d’ajouter une fonction responsable du retardement aléatoire de la réponse du serveur :
Néanmoins, le problème avec ce type de solution est qu’il ne permet toujours pas de contrôler des situations telles que le ralentissement du réseau lors de la tentative de connexion à la base de données ou les différences qui apparaissent lorsque la base de données croît de manière significative.
Une meilleure solution semble être d’effectuer les opérations de validation des données fournies par l’utilisateur de manière asynchrone en arrière-plan et de notifier immédiatement l’utilisateur de la tentative de connexion. Dans ce cas, les calculs et les retards associés resteront invisibles pour l’attaquant.
