Sécurité par obscurité

Bienvenue dans l’épisode 14 ! On va continuer un peu sur la sécurité, après un épisode complet sur une approche générale et un autre sur les injections. Il nous reste deux types de failles du top 10 de l’OWASP, et dans ma grossière qualification ça donne : “faux et usage de faux” (impostures, arnaques…) “la porte était ouverte” (ou une autre porte) “trop d’infos disponibles” La sécurité par l’obscurité Mais dès qu’on se dit que laisser trop d’infos c’est une mauvaise sécurité, on pourrait croire qu’une bonne sécurité c’est laisser peu d’informations. Bien entendu, ça ne suffit pas. Trop d’infos, ça augmente les chances qu’un attaquant trouve une porte d’entrée, et pourquoi pas un moyen spécifique de l’attaquer (on réduit les possibilités auxquelles il devrait se préparer), mais la base reste quand même d’avoir toutes ses portes bien sécurisées. Si votre clé est sous le paillasson ou sous un pot de fleurs, elle n’est pas en évidence, mais vous avez quand même un double dans la nature et vous ne faites qu’espérer que personne ne le trouvera. Au lieu de vous dire “ma porte et ma clé sont sécurisées”, vous devez alors vous assurer que : personne n’ira par hasard chercher sous le paillasson lors des rares occasions où je dois chercher mon double, personne ne me voit quand je donne la cachette à une connaissance, personne n’entend Et bien sûr puisque vous avez transmis votre confiance, s’assurer que cette personne mérite cette confiance, ne fera pas de double, n’ébruitera pas votre secret, etc. Passe et Backdoor Entre parenthèses, c’est tout à fait l’enjeu du récent procès entre Apple et le FBI : autoriser une “Master Key”, un passe, surtout si c’est public, fait que les attaquants ne vont plus nécessairement chercher à pirater les maisons une par une, mais simplement tenter de récupérer le passe qui leur ouvrira d’un coup toutes les maisons. La porte n’était pas fermée La sécurité d’une chaîne est celle de son maillon le plus faible. L’adage est connu. Le plus bête : vous avez une super porte, mais vous avez oublié de la fermer en partant. C’est le cas “mauvaise configuration” de l’OWASP : vous avez des outils, qui sont bons et bien choisis, mais vous les utilisez de travers, ou vous oubliez de les brancher. La fenêtre était ouverte Presque aussi bête, puisque ça ne vient pas de vous : une de vos dépendances est vulnérable. La porte d’entrée est fermée, mais il y a une fenêtre ouverte au rez-de-chaussée. Tous nos systèmes informatiques et tous nos logiciels sont composés de nombreuses petites parties qui s’articulent entre elles. Si vous vous basez sur tel outil ou telle bibliothèque un peu vieille, sa dernière version a peut-être mis des correctifs de sécurité. Ne pas la mettre à jour, c’est risquer de se faire attaquer par là. Le problème c’est que les dépendances d’un logiciel sont de plus en plus nombreuses et ajoutent elles-mêmes d’autres dépendances. La vérification de chacune devient vite pénible, sauf si vous la faites automatiquement. Heureusement, chaque langage et framework vient de plus en plus avec son gestionnaire de dépendances, et outre les commandes pour installer et mettre à jour des paquets, ces outils proposent souvent aussi de lister les paquets à mettre à jour, obsolètes etc. La porte est restée ouverte trop longtemps C’est un peu le cas du fraudeur qui passe le portillon du métro derrière d’autres : la porte est là, elle marche, elle est plutôt bien dimensionnée, mais il y a des cas où c’est ouvert trop grand, trop longtemps etc. Ce n’est pas suffisant, mais c’est la raison pour laquelle certaines applications vont vous déconnecter après un temps d’inactivité, vous faire changer de mot de passe de temps à autre, vous rappeler de supprimer les accès qui n’ont plus raison d’être, rappeler de ne pas prêter son badge, etc. L’accès pièce par pièce, placard par placard Enfin, la métaphore a là aussi atteint ses limites d’utilité. Je parlais de la sécurité de votre habitation, et il y a un “dehors” et un “dedans”. Une fois “dedans” on peut tout faire. Dans un logiciel, on peut et on veut souvent être bien plus spécifique : une zone pour les administrateurs et une zone pour les clients, très souvent. On pourrait dire aussi : une zone pour la gestion de stock, une autre pour la comptabilité. Un accès pour la succursale de chaque département, et un accès global pour consolider les infos. Imaginez une telle finesse chez vous : le facteur peut entrer s’il a un trop gros colis, mais ne peut que laisser un colis dans l’entrée ; la voisine peut nourrir le chat, mais pas aller dans les chambres ; les enfants ont accès aux placards pour les boissons et le repas, mais pas pour piller les desserts et les bonbons. L’une des failles d’OWASP est d’oublier ou de mal configurer ce genre d’accès. Dans leur section propre à Ruby on Rails, ça donne même un conseil de plus : utiliser les “strong parameters” pour que le concept “modifier un enregistrement” se limite à certains champs, et eux seuls. Je laisse trop d’infos Maintenant qu’il est clair que cacher des choses ne vous sauvera pas, on garde quand même la logique de rendre les attaques plus dures, plus longues, plus complexes et plus visibles. Bref, on peut quand même éviter de simplifier les attaques. Par exemple, un attaquant peut tenter de vous envoyer un email en se faisant passer pour votre banque. S’il se trompe de banque, non seulement il ne vous aura pas, mais en plus il va potentiellement vous mettre la puce à l’oreille pour la prochaine tentative. S’il fait un envoi de plusieurs spams avec chacune des banques les plus probables, l’attaque est plus longue et plus visible, et vous vous doutez non seulement qu’on vous en veut, mais d’où les attaques viennent en ce moment. En cas de doute, vous serez plus enclin à appeler votre banque pour confirmation, et elle vous précisera en général comment identifier un mail qui vient bien de chez eux, et vous précisera probablement que JAMAIS ils ne vous demanderont de mots de passe ou données confidentielles par email. German Tank Problem De même, si vos identifiants sont numériques et croissants, sans même vouloir vous attaquer, vos concurrents sont capables de voir votre progression : tiens, mon compte test d’hier est le numéro 300, mon compte test d’aujourd’hui est le numéro 400, et l’entreprise prétend avoir des milliers d’inscriptions par jour, et des millions d’utilisateurs au total ? Peu crédible. Open API Laisser trop d’infos, comme vos identifiants ou la liste de vos champs, très classique dans le cas d’une API ouverte à l’extérieur, permet à un attaquant de mieux cibler ses tentatives d’injection. Si je sais qui sont les admins, où est le champ qui donne les droits… CSRF Tout cela nous mène au dernier point, la CSRF, prononcée Sea-Surf, pour Cross-Site Request Forgery : fausse requête de site à site. Si un attaquant sait que votre site a une URL qui fait quelque chose, par exemple vous désinscrire, ou valider un transfert d’argent, ou vous faire voter dans un concours en ligne qui l’intéresse, il peut en profiter pour vous faire cliquer ou vous faire faire une requête du genre, depuis un autre site, par exemple avec un lien “cliquez ici pour voir des photos de chatons”. On se protège rarement de cela pour des requêtes en lecture (GET), mais pour un formulaire qui envoie des informations, Rails va souvent ajouter son CSRF-token, un “jeton unique” avec une clé qui permet de se dire “tiens, l’utilisateur souhaite voter pour le concours, mais pourtant il ne connaît pas la clé que je lui ai donnée, c’est donc qu’il vient probablement d’un endroit que nous n’avions pas prévu”. OWASP TOP 10 Bref, révision rapide du top 10 de l’OWASP : Faussaires, imposteurs et passe-passe 1. injection SQL ?. injection shell 3. XSS (Cross-Site Scripting) 10. redirections non vérifiées Je laisse la porte ouverte 5. Mauvaise configuration 9. Dépendances vulnérables 2. Authentification / gestion des sessions 7. Missing function level access control ?. Oubli des `strong parameters` Je laisse trop d’infos 4. Insecure direct object references 6. Sensitive data exposure Un peu un mix : 8. CSRF - Cross Site Request Forgery vous avez confiance en votre browser mais il est prédictible et je vous ferai cliquer sur un lien Je pense que pour la suite du sujet je vais vous laisser vous documenter auprès de qui de droit, la technique et les sujets pointus ne tiendront pas dans un format audio ni en 5~10mn, et j’espère que vous avez une meilleure idée de la sécurité, ses enjeux, et les endroits où vous pouvez intervenir. À bientôt !