𝗦é𝗰𝘂𝗿𝗶𝘁é 𝗱𝗲𝘀 𝗰𝗼𝗻𝗻𝗲𝘅𝗶𝗼𝗻𝘀 𝘀𝗶𝗺𝘂𝗹𝘁𝗮𝗻é𝗲𝘀
Des connexions illimitées peuvent masquer de graves failles de logique métier.
Un utilisateur se connecte sur un ordinateur portable. Quelques secondes plus tard, le même compte se connecte sur un autre navigateur. Puis sur un appareil mobile. Puis via un client API. Tout fonctionne parfaitement.
Cela semble normal car de nombreuses applications prennent en charge plusieurs appareils. Mais vous devez vous poser la question : chaque application doit-elle autoriser des sessions illimitées ?
Dans certains systèmes, les sessions multiples sont une fonctionnalité. Dans d'autres, c'est une faille que les attaquants utilisent pour rester discrets. Il s'agit d'une vulnérabilité de logique métier. Le code fonctionne comme prévu, mais la conception elle-même est défaillante.
La différence : • Les bugs traditionnels exploitent des erreurs de codage. • Les bugs de logique métier exploitent des décisions de conception.
Pensez à un service de streaming de films. Si un seul abonnement permet à dix personnes de regarder en même temps, le système de connexion fonctionne. C'est la règle métier qui échoue.
Cela s'applique aux services bancaires, aux panneaux d'administration et aux produits SaaS.
Comment tester cela :
- Connectez-vous via le navigateur A et maintenez la session active.
- Ouvrez une fenêtre de navigation privée dans le navigateur B.
- Connectez-vous avec les mêmes identifiants.
- Vérifiez si la première session fonctionne toujours.
- Vérifiez si vous pouvez effectuer des actions sensibles sur les deux.
Les applications à haute sécurité imposent souvent ces règles :
- Une seule session active par compte.
- Déconnexion des anciennes sessions lorsqu'une nouvelle connexion survient.
- Contrôles pour gérer les appareils.
- Alertes pour les nouvelles connexions.
Si un attaquant vole des identifiants, il peut rester connecté indéfiniment si vous autorisez des sessions illimitées. Il reste actif pendant que l'utilisateur réel reste actif. Personne ne remarque l'intrus.
Le contexte est primordial. Applications nécessitant de nombreuses sessions :
- Applications de messagerie.
- Réseaux sociaux.
- Services de messagerie électronique.
Applications nécessitant un contrôle strict :
- Systèmes bancaires.
- Tableaux de bord d'administration.
- Plateformes de santé.
Comment corriger cela :
- Stockez les ID de session actifs dans une base de données.
- Lorsqu'une nouvelle connexion survient, mettez fin à l'ancienne session.
- Permettez aux utilisateurs de voir les appareils et les emplacements actifs.
- Ajoutez un bouton « Se déconnecter de tous les appareils ».
- Envoyez des alertes par e-mail ou SMS pour les nouvelles connexions.
Ne cherchez pas seulement des bugs de code comme l'injection SQL. Cherchez les écarts entre ce que fait votre application et ce que votre entreprise exige.
Révisez votre politique de session dès aujourd'hui. Votre plus grand risque n'est peut-être pas un code défectueux, mais une logique défaillante.