Skip to main content
BlogSécuritéInutile n'est peut-être pas inoffensif : L'histoire d'une page de connexion avec une question de sécurité vide

Inutile n'est peut-être pas inoffensif : L'histoire d'une page de connexion avec une question de sécurité en blanc

Illustration d'un écran de saisie d'une question de sécurité et d'une réponse, avec le texte Pointless May Not Be Harmless.

Les applications web sont souvent la cible d' attaquants malveillants. Ces applications sont accessibles au public - ou du moins, leurs pages de connexion le sont - et il n'est pas difficile pour un attaquant déterminé de trouver des sites présentant des failles de sécurité. Les attaquants tentent souvent d'exploiter les vulnérabilités de sécurité des pages de connexion d'une application web afin de provoquer une charge excessive et, éventuellement, de faire tomber le site.

L'une de ces vulnérabilités se trouve dans la page de questions de sécurité qui fait partie de nombreux flux de connexion. Dans ce billet, nous examinerons ce scénario, nous verrons pourquoi il pose problème et nous donnerons des conseils sur la manière de réduire ce risque de sécurité.

La page de connexion avec une question de sécurité vide

Les failles de sécurité des pages de connexion sont plus fréquentes qu'on ne le pense. Dans le processus de connexion de nombreux sites web et applications, une vérification supplémentaire vient compléter l'étape traditionnelle du nom d'utilisateur et du mot de passe pour une sécurité accrue. Imaginez un processus de connexion en deux étapes. Lors de la première étape, le site vous demande un nom d'utilisateur et un mot de passe. Si vous saisissez correctement ces informations d'identification, la deuxième étape vous demande de répondre à une question de sécurité (que vous avez spécifiée lors de la création de votre compte).

Cette deuxième étape est généralement construite à partir d'un modèle de page qui insère la question de sécurité en fonction de l'utilisateur qui a réussi la première étape. L'ensemble du flux de connexion en deux étapes fonctionne essentiellement de la manière suivante :

  • Alice se rend sur la page de connexion à l'adresse https://www.example.com/login.
  • Alice soumet une combinaison de nom d'utilisateur et de mot de passe.
  • Le serveur vérifie les informations d'identification soumises.
  • Les informations d'identification étant correctes, le serveur redirige le navigateur vers la page de suivi à l'adresse https://www.example.com/login2, en incluant un jeton unique dans l'en-tête de la demande pour vérifier qu'Alice a franchi la première étape de la procédure de connexion.
  • Le serveur rend cette page sur la base d'un modèle, en insérant la question de sécurité recherchée pour Alice, ainsi que la saisie de texte pour une réponse et un bouton d'envoi.
  • Alice soumet la réponse à sa question de sécurité.
  • Le serveur vérifie qu'Alice a répondu correctement à sa question de sécurité et la connecte.

Concentrons-nous sur la deuxième page du flux, à l'adresse https://www.example.com/login2. Imaginez ce qui se passerait si vous visitiez cette page directement dans votre navigateur, sans passer par la première étape.

Dans un scénario, il est possible que le serveur vérifie qu'il n'y a pas de jeton valide dans l'en-tête de la demande (ce qui signifie que vous n'avez pas passé avec succès la première étape du flux de connexion) et qu'il vous redirige simplement vers https://www.example.com/login afin de recommencer.

Toutefois, dans un autre scénario possible, le serveur rend toujours la page sur la base du modèle. Incapable de trouver une question de sécurité correspondante pour l'utilisateur (puisqu'il n'y a pas de jeton indiquant au serveur de quel utilisateur semi-authentifié il s'agit), la page résultante pourrait ressembler à ceci :

vulnérabilités de la page de connexion

Vous vous retrouvez avec une page de questions de sécurité gênante qui n'a... aucune question de sécurité. C'est une page inutile.

Inutile, oui. Mais inoffensif ? N'en soyez pas si sûr.

Les implications en matière de sécurité

En poursuivant ce scénario, que se passe-t-il lorsque vous (ou une personne plus malveillante que vous) soumettez une réponse à cette "question de sécurité" ? Le serveur consacrera des cycles de l'unité centrale à l'évaluation de votre réponse. Il traitera le texte saisi, recherchera le jeton unique dans l'en-tête de la demande et exécutera peut-être même une requête de base de données pour tenter de valider votre réponse.

Une page de connexion avec une question de sécurité vide peut sembler mineure(qu'y a-t-il de mal à gaspiller quelques cycles de CPU ici et là ?), mais elle peut entraîner de graves problèmes de sécurité.

  • Ressources de traitement du backend gaspillées: Le traitement des formulaires inutiles consomme des ressources informatiques et de réseau, voire des ressources de base de données.
  • Possibilité d'attaques par déni de service (DoS): Un pirate pourrait mettre en place un réseau de zombies pour envoyer des formulaires de manière répétée, surchargeant ainsi le système.
  • Vulnérabilité accrue: Une attaque par déni de service réussie peut entraîner l'effondrement de l'ensemble de votre système.

Si des attaquants parviennent à exploiter cette faiblesse pour gaspiller la puissance de traitement d'un serveur, ils risquent de perturber les services offerts aux utilisateurs légitimes et d'exposer le système à d'autres attaques.

Pas si inoffensif que ça, finalement.

Voyons comment remédier à ces vulnérabilités afin de maintenir la sécurité et la fiabilité de vos applications.

Comment se défendre

Pour ce scénario spécifique, le serveur qui gère le point d'accès login2 doit vérifier l'existence d'un jeton valide dans l'en-tête de la requête. Sans jeton valide, aucun traitement supplémentaire ne doit avoir lieu, et l'utilisateur doit être redirigé vers la première étape du flux de connexion. De cette manière, vous minimisez les ressources utilisées pour traiter la demande avec élégance, comme vous le feriez pour un 404 ou un 401.

Toutefois, ce scénario met en évidence un problème de sécurité plus général auquel vous devez faire attention : les requêtes répétées qui imposent une charge excessive à votre serveur. Certes, l'exploitation d'une page de connexion inutile avec une question de sécurité vide peut surcharger votre serveur plus rapidement en raison de la quantité de ressources de traitement utilisées. Mais un réseau de zombies peut également soumettre votre page de connexion avec un nom d'utilisateur et un mot de passe tout à fait normaux à des demandes excessives.

Pour protéger vos applications web contre ce type d'attaques, mettez en œuvre les mesures suivantes :

  • Utilisez un pare-feu d'application web (WAF): Un WAF peut fournir une protection contre les attaques DoS et détecter et bloquer les robots malveillants, réduisant ainsi le risque d'attaques automatisées. La place de marché d'applications de Linode comprend le Haltdos Community WAF qui peut vous aider à cet égard.
  • Mettre en place une limitation de débit: Limitez le nombre de requêtes qu'une même adresse IP peut effectuer dans un laps de temps donné. En limitant le nombre de requêtes, vous empêcherez les attaquants (et les robots) d'inonder votre système de requêtes.
  • Mettre en place un système de surveillance et d'alerte: Les outils de surveillance continue peuvent être à l'affût de schémas de requête suspects et vous alerter en temps réel des attaques potentielles. Lorsque vous êtes averti immédiatement, vous pouvez réagir et atténuer le problème rapidement.

Conclusion

Nous avons examiné le cas d'une page de connexion comportant une question de sécurité vide. À première vue, il s'agit d'une page étrange qui ne sert finalement à rien. Mais les attaquants peuvent exploiter des vulnérabilités de ce type pour gaspiller vos ressources et potentiellement faire tomber votre système. La page de question de sécurité n'est qu'un exemple d'une telle vulnérabilité.

Si vous concevez vos applications en tenant compte de la sécurité et que vous adoptez des pratiques de codage sécurisées, vous avez pris un bon départ. Toutefois, vos applications doivent également faire l'objet de mesures de sécurité au niveau du système et de l'infrastructure, telles que l'utilisation d'un WAF, la limitation du débit, la surveillance continue et les alertes. En mettant en place les mesures de sécurité appropriées, vous pouvez réduire considérablement le risque d'être la cible de telles attaques.

Pour plus de conseils et d'astuces sur la sécurisation de vos applications, consultez la documentation Linode, avec sa riche bibliothèque de guides sur la sécurité. Vous y trouverez des ressources utiles pour vous aider à protéger vos systèmes et vos utilisateurs.

Commentaires

Laissez un commentaire

Votre adresse électronique ne sera pas publiée. Les champs obligatoires sont marqués d'un *.