Les failles de sécurité sont-elles acceptables si peu de dommages peuvent en découler?
Récemment, j'ai découvert une faille de sécurité dans un site Web d'entreprise. Ce site Web possède une "Zone Partenaires" protégée par mot de passe et, comme de nombreux sites Web, il fournit un formulaire pour réinitialiser le mot de passe de l'utilisateur.
Lorsqu'un utilisateur demande une réinitialisation du mot de passe pour son surnom, un nouveau mot de passe est envoyé à son adresse e-mail et ce mot de passe devient immédiatement effectif. Le problème est (si ce n'était pas déjà un problème) que le nouveau mot de passe est fixe, pour tous les utilisateurs. Ainsi, un attaquant peut facilement accéder à n'importe quel compte.
Désormais, les seules opérations qu'un utilisateur peut effectuer dans sa zone Partenaires sont:
- Afficher/modifier l'adresse e-mail
- Changer le mot de passe
- Téléchargez des manuels et des utilitaires (ce n'est certainement pas classifié)
- Remplissez un formulaire de réparation (le processus se poursuivra par e-mail)
- Télécharger des logos et des images à des fins marketing
Les seules choses que je vois pour un attaquant malveillant à exploiter sont:
- Empêcher tout accès futur à un utilisateur légitime (qui sera probablement en mesure de le récupérer immédiatement après un appel téléphonique)
- Découvrez des informations sur qui sont les clients de l'entreprise (en devinant des surnoms aléatoires et en regardant leur adresse e-mail). De toute façon, ce n'est pas quelque chose que quelqu'un garderait secret.
Même si je suis toujours très perturbé par des choses comme ça, dans ce cas, je dois admettre que ce n'est peut-être pas un gros problème. Les défauts comme celui-ci sont-ils des compromis acceptables, dans un contexte où peu de dommages peuvent être causés?
Puisque je pense que quelqu'un a mal compris un détail: ce site Web appartient à une entreprise externe. Je n'ai aucun rôle dans le développement de ce site Web et aucun contrôle sur toute décision à ce sujet.
Votre question est: Les failles de sécurité sont-elles acceptables si aucun mal ne peut en découler?
La réponse est oui, si cela est décidé par les entreprises tout en comprenant les conséquences.
Ce que vous faites s'appelle une évaluation des risques. Pour chaque risque, vous devez mettre en évidence les conséquences pour votre entreprise lors de son instanciation. Sur la base de cette évaluation, vous (vous = quelqu'un qui a le pouvoir de prendre la décision entreprise) avez trois choix:
- vous pouvez accepter it - en supposant que les coûts de sa réparation ne valent pas les conséquences
- vous pouvez atténuer it: le réparer au point où vous pouvez accepter les conséquences
- vous pouvez assurer contre cela - décharger efficacement le risque à quelqu'un d'autre.
Comme vous pouvez l'imaginer, il existe plusieurs zones sensibles dans une évaluation des risques.
Le premier est l'évaluation des conséquences et de la probabilité. Il existe de nombreux livres et articles sur la façon de le faire, en fin de compte, cela est basé sur une agitation vigoureuse de la main et sur l'expérience. La sortie n'est jamais comme celle des livres
nous avons une probabilité de 76% que cela se produise, ce qui nous coûtera 126 653 €
mais plutôt
eh bien, je pense que c'est un risque dont nous devons nous occuper
Notez que la partie "conséquences" peut parfois être quantifiable (perte de profit pour le commerce en ligne par exemple) mais ne l'est généralement pas (perte d'image pour votre entreprise par exemple).
Outre les aspects théoriques douteux de l'évaluation des risques, il y a un énorme avantage dont vous devriez toujours profiter: vous mettez un risque sur la table et il doit être traité d'une manière ou d'une autre.
Ce n'est pas seulement un endroit où le dos perd son noble nom, c'est le bon outil pour mettre en évidence où les efforts de sécurité de l'information doivent aller. Cela augmente également votre visibilité (il n'y a pas tellement de cas proactifs où vous pouvez augmenter votre visibilité) et vous oblige à porter un regard dur, profond et pragmatique sur ce qui est important et ce qui ne l'est pas.
Oui. C'est un problème - un gros problème. Dernièrement, j'ai trouvé un défaut de conception dans la boutique en ligne d'une entreprise qui m'a permis d'insérer des notes innocentes dans les cartes des autres visiteurs.
Semble innocent, et seulement ennuyeux, jusqu'à ce que je regarde plus loin et trouve que j'ai également été en mesure d'insérer du code Javascript (XSS) dans ces notes. En d'autres termes, je pourrais exploiter XSS sur la carte de chaque visiteur. J'ai fait un PoC rapide en leur montrant comment je pouvais facilement pirater l'ordinateur de n'importe quel visiteur (dans ce cas moi-même, c'était un PoC) en utilisant ce défaut de conception, XSS, BeEF et Metasploit.
Ainsi, même le plus petit défaut peut entraîner un gros risque après tout.
En plus de cela, qui a dit que l'erreur que vous avez trouvée était la seule que le développeur de ce site Web ait commise? Peut-être qu'il a également fait des tonnes d'autres erreurs.
Le signalement serait le meilleur que vous puissiez faire - même s'il semble inutile.
Le problème que je vois avec un schéma de réinitialisation de mot de passe aussi simple est qu'il suggère d'autres vulnérabilités dans la plate-forme. Un concept défectueux de sécurité est rarement aussi isolé qu'il ne peut se produire qu'une seule fois, car ces défauts sont généralement liés aux pratiques d'un développeur en matière de sécurité. Au minimum, je soupçonne que leurs procédures de connexion internes pourraient également être sensibles à la même faille, permettant potentiellement aux attaquants d'accéder aux bases de données, au code et aux processus auxquels ils ne devraient normalement pas avoir accès.
À partir de là, il pourrait être possible de modifier le code du serveur pour signaler des mots de passe en texte clair, ou glaner des informations privées supplémentaires, et éventuellement autoriser des attaques sur d'autres systèmes. Après tout, même si nous sommes en 2016, il y a encore beaucoup de gens qui utilisent toujours le même mot de passe pour leurs comptes bancaires que Facebook, malgré les risques évidents associés à cela. Même si ce n'est pas le cas, la possibilité d'associer un surnom à une adresse e-mail peut également mettre d'autres comptes en danger pour l'utilisateur; plus un attaquant connaît d'informations sur un compte d'utilisateur, plus il peut tirer parti de la tentative de détournement d'autres comptes appartenant à la même personne.
Au minimum, je vous suggère de contacter le propriétaire du site et de voir s'il résoudra le problème, et sinon, envisagez de ne pas utiliser leur application à moins que cela ne soit absolument vital. Je recommanderais également de changer votre adresse e-mail sur le compte utilisateur en un compte jetable qui n'est pas connecté à une adresse e-mail qui vous tient à cœur. Nous ne sommes plus à une époque où nous pouvons supposer que des défauts apparemment mineurs ne reviendront pas nous hanter plus tard.
Si je vois bien ce scénario, ils peuvent changer l'adresse e-mail et le mot de passe de n'importe quel compte, puis démarrer un formulaire de réparation et continuer le processus de réparation par courrier.
L'équipe d'assistance supposera probablement que l'adresse e-mail est légitime et que des informations sensibles peuvent être échangées avec le destinataire - et s'il s'agit d'un client connu, vous pourriez même commencer à travailler sur une commande reçue via le site Web/courrier.
Un autre problème pourrait être si vous pouvez accéder à l'historique des contacts ou à l'historique de vos ordres de réparation? Peut-être qu'un client a écrit des informations confidentielles dans ses ordres de réparation, ou même le nombre et le type de commande peuvent révéler des problèmes dans son entreprise?
Un autre problème pourrait être un spamming massif des adresses e-mail des clients. Si j'invoque votre mot de passe réinitialisé un million de fois, il enverra un million de courriels à vos utilisateurs, non seulement en remplissant leur boîte de réception, mais également en vous atterrissant sur plusieurs listes de filtres anti-spam ... où il peut être assez compliqué d'obtenir votre serveur supprimé de ces listes par la suite.
DoS est bien sûr très facile, si je dois simplement énumérer les surnoms et réinitialiser tous les mots de passe des comptes.
Mais le plus gros problème est un faux sentiment de sécurité
Il se peut que nous ignorions un angle ou un problème qui existe actuellement. Mais même s'il n'y a pas de problème maintenant - Et si quelqu'un décide d'implémenter une nouvelle fonctionnalité dans cette page l'année prochaine? Peut-être pour les clients de commander/payer en ligne. - Vous fournissez un contexte qui est uniquement accessible avec un nom d'utilisateur et un mot de passe et les personnes et les développeurs s'appuieront sur cela. Tout le monde pensera "ceci est une partie sécurisée de l'application à laquelle seuls les clients peuvent accéder afin que je puisse faire X et compter sur Y"
Si une application est pratiquement accessible au public, elle devrait ressembler à cela. Si l'application semble sécurisée, elle devrait l'être!
Il y a deux perspectives ici:
- En tant qu'utilisateur, oui, je serais inquiet, je le ferais savoir au propriétaire et je m'abstiendrais de partager toute information sensible sur ce site.
- En tant que propriétaire/développeur du site, il est de votre responsabilité d'évaluer si un risque de sécurité potentiel est suffisamment sérieux pour justifier des efforts. Tous les risques ne seront pas suffisamment graves pour justifier une action, à en juger par la probabilité d'occurrence, l'impact d'une violation et les efforts requis pour contrôler le risque.
Dans ce cas, vous avez (à une supposition):
- gravité: faible
- probabilité: modérée
- effort: faible
et donc ils ont probablement devraient faire quelque chose à ce sujet; il y a de très bonnes chances qu'ils ne soient tout simplement pas conscients du problème.
Dans le cas général, en réponse à votre question "Les failles de sécurité sont-elles acceptables si aucun mal ne peut en découler?" - oui, ils peuvent l'être. Vous devez déterminer si le compromis gravité/probabilité/effort vaut la peine de résoudre un problème. "Accepter le risque" est une réponse parfaitement raisonnable dans de nombreux cas.
À titre d'exemple extrême, "des extraterrestres qui peuvent briser une crypto-visite forte visitent la Terre" est un risque auquel mon entreprise est confrontée. Je choisis de ne pas contrôler ce risque car la probabilité qu'il se produise est si faible qu'il n'en vaut pas la peine.
C'est une bonne question à laquelle il n'est pas facile de répondre.
Chaque risque de sécurité n'est que cela, un risque. Et faire face à ce risque doit peser le coût, la confusion et les dangers du risque, par rapport au correctif proposé.
En regardant votre question spécifique, vous avez une partie "privée" du site, qui contient des informations, mais aucun préjudice réel ne peut provenir d'une personne accédant à cette partie du site. Votre faille de sécurité nécessite également que le pirate informatique sache que chaque mot de passe est réinitialisé à la même chose, et quelle est cette chose.
Donc, en ce moment, aujourd'hui, votre plus grand risque n'est rien ou du moins faible.
Demain, votre plus grand risque est que la section privée contienne des informations confidentielles.
Le coût de la "réparation" semble assez faible. Surtout si vous envoyez déjà le nouveau mot de passe "fixe". Essentiellement, il suffit de changer l'attribution du mot de passe au hasard et le problème est "résolu" pour l'instant. Ce n'est peut-être pas le meilleur mais c'est mieux.
Ainsi, vous avez un faible coût à réparer, mais un faible risque de sécurité. Vous devez comparer cela aux besoins de l'entreprise et déterminer si cela en vaut la peine.
Gardez à l'esprit que l'entreprise peut compter sur ce mot de passe fixe. Par exemple, le personnel d'assistance peut avoir été formé pour réinitialiser le mot de passe, puis indiquer à l'utilisateur au téléphone le nouveau mot de passe et rester avec lui jusqu'à ce qu'il puisse entrer, puis l'aider à le changer. Vous devez en tenir compte lorsque vous calculez les coûts.
Ce que je fais:
Lorsque je trouve un bogue ou un problème de sécurité, je le documente et j'évalue un coût de développement à corriger. Ensuite, je l'ajoute à une liste et informe les bonnes personnes. Il ne sera peut-être jamais retiré de cette liste, mais une fois par an (ou tous les 6 mois) je passe en revue cette liste avec les propriétaires du site et je résous les problèmes que je peux.
Avec ce risque, il ne serait probablement pas réglé très rapidement. Je pouvais voir beaucoup de besoins commerciaux venir en premier, et ça va. Mais au moins c'est documenté, et quand quelqu'un me dit qu'il veut mettre des informations "secrètes" dans cette partie du site, je peux lui parler du risque.
Il est également important de noter que ce type de risque est susceptible d'entraîner d'autres types de risques. Lorsque cela a été codé, une mauvaise décision de sécurité a été prise. Le site doit être vérifié pour d'autres mauvaises décisions.
L'usurpation de l'identité d'un utilisateur légitime d'un client (qui est considéré comme approuvé dans une certaine mesure) est un bon moyen de lancer une attaque basée sur l'ingénierie sociale.
Un formulaire de réparation -> processus de courrier électronique est idéal pour cela étant donné que vous contrôlez l'adresse e-mail. Peut-être pourriez-vous acheter un domaine similaire et changer l'adresse e-mail "quelqu'[email protected]" -> "quelqu'[email protected]", ce qui correspond bien à "Je viens de transférer à notre filiale canadienne donc je n'ai pas mon records, pourriez-vous me rappeler ...? "
Si vous pouvez obtenir un peu d'informations sur l'historique du client/fournisseur, vous pouvez encore usurper l'identité du fournisseur auprès du client. Souvent, c'est aussi simple que de demander "Quel était le nom de l'ingénieur de service qui a visité il y a quelques mois? Ils étaient apparemment très utiles sur une question spécifique, mais j'étais absent et mon collègue s'en est occupé"
Non, si l'utilisateur accède à ce site, il pourra accéder au courrier électronique de quelqu'un en utilisant son surnom qui est données confidentielles, dans certains pays, cela suffit pour vous forcer à AVISER TOUS LES UTILISATEURS que quelqu'un a pu pénétrer dans la base de données et qu'il y a eu une fuite d'informations. Cela nuit à la crédibilité et ouvre des poursuites.
Donc, en général, les failles de sécurité sont acceptables, mais ce n'est peut-être pas une faille de sécurité acceptable. Cela est également ouvert à tous les types de spam que vos utilisateurs pourraient soudainement commencer à recevoir logiciels malveillants et spam par e-mail.
Les pirates sont toujours créatifs pour mettre à profit (pour eux) les défauts qu'ils ont trouvés. Vous supposez que l'identité des utilisateurs n'est pas une information cruciale, mais cela pourrait l'être s'il s'agit par exemple d'un site Web de triche. De plus, que se passe-t-il si un utilisateur faisait activement de la promotion contre un membre d'une secte/secte et de sectes soudaines pour découvrir son identité? Que se passe-t-il si quelqu'un victime de harcèlement est divulgué et grâce à cela, le harceleur peut le retrouver?
La fuite d'identité sans avertir les utilisateurs est une violation de la vie privée, alors faites attention. Les défauts doivent être corrigés et analysés en fonction des risques dès qu'ils sont détectés.
Par exemple, je préférerais que tous mes messages sur le forum soient supprimés plutôt que de permettre à quelqu'un d'accéder à mon adresse e-mail.
N'oubliez pas qu'en tant que développeur, vous pourriez avoir une meilleure idée des risques de sécurité réels qu'un utilisateur. Si un utilisateur découvre que son compte est détourné, il peut supposer que l'utilisateur non autorisé a pu accéder à plus d'informations que ce qu'il est réellement en mesure de faire. Même si aucune information sensible n'est réellement exposée, votre entreprise peut tout de même prendre un coup de réputation.
Tenez également compte du fait que vous ne savez peut-être pas quelles informations sont inoffensives à divulguer. Par exemple, que se passe-t-il si l'utilisateur a un nouveau processus de fabrication révolutionnaire qu'une entreprise concurrente essaie de comprendre? Si un équipement spécial utilisé dans le nouveau processus doit être réparé et que son e-mail est modifié, l'ordre de réparation peut donner à l'autre société une idée de ce qu'est son nouveau processus.
Cela ressemble à une solution simple et, finalement, vous devrez effectuer cette évaluation pour voir si le risque vaut le coût de sa correction.