14 réflexions sur « NipDev 6 – Sécurité bien ordonnée commence par soi-même »

1. Je trouve que ça fait bizarre de vous écouter en stéréo: un coup à droite, un coup à gauche selon qui parle.
   Je croyais au début avoir un soucis avec mon casque 😉

   Podcast très intéressant, vous avez bien raison de rappeler que la sécurité est importante, je lis trop souvent des developpeurs qui ne s’en soucient pas ou considère qu’ils n’ont pas le temps de s’en occuper 🙁
   Personnellement j’ai dédié une page sur la sécurité de mon framework pour indiquer ce qui était géré par le framework et comment, et surtout ce qui est à la charge du développeur: http://mkdevs.com/security.html
   Mais effectivement, pour une application publique il vaut mieux demander à une société externe de vérifier la sécurité de celle-ci 🙂

   Pour la sécurité, vous n’avez pas parlé de tout au menu XSS/XSRF/SQL Injection et Null Byte 😉
   Vous avez parlé de Sql injection et XSS (peu en fait) et oublié les autres 🙁

   Pour les données: authentification et surtout isolation des données: on ne doit pas pouvoir valider/regarder la commande d’un autre client en changeant une variable dans l’URL 🙂
   Autre chose toute bête pour les cookies: http-only (pour que le javascript ne puisse pas lire le cookie de session)
   voir secure si votre application est en https 😉

   Bien vérifier que son framework gère bien ceci et connaitre les variables/méthodes à utiliser pour en profiter 🙂
   Par exemple j’étais déçu de lire que Yii parlait de sécurité et de voir dans le code en question que ce n’était pas le cas : mal géré en fait :'( (d’où l’utilité de travaillé avec des sociétés de sécurité )

   Pour l’obscursation, il ne faut pas se baser dessus, il faut penser que tout ce que l’on fournit au client (html/js) peut être lu et réutiliser contre nous. (on peut modifier un input hidden, on peut appeler une requête ajax avec d’autres arguments…)

   Donc bien penser à ne pas mettre des informations critiques dans vos js.

   Répondre

   1. Merci Mika. Tes compléments sont toujours très intéressants.

      Répondre

      1. Merci, votre compliment me va droit au coeur 😉
         Question HS: vous avez un compte sur developpez.com ?

         Répondre

         1. Non pas de compte sur développez.com

            Répondre

            1. Dommage, je pense que vous pourriez beaucoup abordé dans les forums techniques ou en réactions à certaines news/billets 😉

      2. Le mkframework a son tutoriel dans le magazine Programmez! 167 de ce mois-ci.

         http://programmez.com/

         Répondre

2. Super un nouvel épisode, je n’ai pas encore eu le temps de l’écouter ça m’occupera sur le chemin du retour mais je tenais à vous remercier pour votre podcast que j’ai trouvé d’une grande qualité depuis le début.
   Continuez comme ça c’est toujours un plaisir et c’est de plus très instructif quand on est débutant ou même quand on connait déjà le sujet un rappel un autre point de vue ne fait jamais de mal

   Répondre

3. Bonjour NipDev!

   Bravo pour votre podcast que je suis depuis le début et que je trouve très intéressant. Je le recommande à tous les développeurs dans mon entourage. Par contre, j’aimerais corriger/préciser quelques petites choses par rapport à votre introduction sur la cryptographie.

   Ca n’a pas de sens de dire que la cryptographie asymétrique est plus « secure » que la cryptographie symétrique. On compare des pommes et des poires. Ce sont deux outils avec leur avantages et inconvénients et ils sont complémentaires. Si on veut vraiment comparer les deux méthodes/mondes, il faut aller plus loin que ça, et là on sort de la vulgarisation.

   En cryptographie asymétrique, la sécurité de ces algorithmes est souvent basée sur un problème difficile à résoudre mathématiquement. Dans le cas de RSA (ça devrait vous rappeler les RSA id par exemple), c’est le problème de factorisation en nombre premier (dans un contexte mathématique particulier). Dans le cadre de la génération d’une clé de session, ou dans d’autres algorithmes, c’est le problème dit du logarithme discret (il est difficile de calculer le logarithme d’un nombre, même si on connaît « le générateur ») qui intervient. Il y a ensuite bien évidemment tout ce qui est cryptographie asymétrique à base de courbes élliptiques.

   Ce que je trouve dommage, c’est qu’il n’a pas été précisé les tailles actuellement « standards »/ »obligatoires » pour les paramètres des algorithmes de chiffrement. Par exemple, 128 bits en symétrique pour AES et 1024 bits en asymétrique pour RSA dans les recommandations actuelles. Ensuite, j’ai l’impression que les algorithmes cryptographiques de hachage qui sont impliqués dans de très nombreux outils (notamment quand on stocke des mots de passes dans des bases de données) n’ont pas été présentées. On ne dépasse pas (à ma connaissance) 256 et 512 bits en terme de taille de clé pour un algorithme symétrique aujourd’hui (ces tailles dépendent des algorithmes sous-jacents). AES, les tailles de clés sont 128, 192 et 256 bits.

   La fausse intuition serait de se dire 1024 > 128 donc c’est mieux. Le problème, c’est que le monde de la cryptanalyse n’aborde par de la même manière les attaques sur ces deux familles (factorisation dans un cas et brute force dans l’autre, par exemple).

   D’ailleurs, j’ajoute deux bonnes références en secure programming:

   – Writing Secure Code, 2nd Edition de Michael Howard, David LeBlanc, MS press
   – Secure Programming Cookbook for C and C++, Jon Viega, Matt Messier, Zachary Girouard

   Si la cryptographie, vous intéresse il y a de bons bouquins très didactiques et disponibles gratuitement sur la page de certains auteurs, si ça vous intéresse faites le moi savoir. 😉

   N’oubliez pas que dans un projet ou un développement aujourd’hui, on doit travailler la sécurité « from the design » avant tout. « Patcher » son code coutera beaucoup plus cher sur le long terme. Certaines méthodologies ont été d’ailleurs développés pour s’intégrer dans des environnements agiles (STRIDE et SDL par exemple).

   Pour le reste, la partie développement est juste super. Ca reste très pédagogique et c’est une magnifique initiative. Peut être que l’étendue du sujet aurait mérité deux émissions. J’attends déjà l’émission suivante avec impatience (notamment sur le networking).

   Bonne continuation et à bientôt!

   PS: désolé si je m’emballe par moment…. déformation professionnelle ^o^

   Répondre

   1. Merci pour ces précisions très intéressantes. L’idée était de balayer assez large pour survoler les sujets, le risque et qu’effectivement, il y a parfois quelques approximations que les auditeurs corrigent ensuite. C’est très bien d’autant plus que nous ne détenons pas la vérité.

      Répondre

4. un très bon livre de vulgarisation de la crypto : http://www.amazon.fr/Histoire-codes-secrets-Simon-Singh/dp/2253150975. Passionnant car ce livre en profite pour aborder de grandes périodes historiques.

   Répondre

   1. Très bon livre et qui se lit comme un roman.

      Par contre je conseillerai plutôt de lire sa version originale : The Code Book.

      La version française souffre de mauvais anglicismes (« encryption », « crypter », etc.). Même si cela reste de la vulgarisation, c’est dommage d’aborder le domaine avec un vocabulaire inexacte.

      Pour une fois que la langue française est pas trop déconnante sur le sujet… 🙂

      Répondre

5. Hello, merci pour le PodCast

   J’ai peut-être zappé vous n’avez pas parlé de Stéganographie ?

   J’ai eu l’impression qu’il y avait un mélange entre OTP (super pratique) et SMS (UX horrible)

   – Côté JS, il me semble qu’il y a une extension Chrome qui fait du GPG pour GMail
   – Sinon en JS il y a aussi encipher.it

   Répondre

   1. Je crois que vous avez parlé SQLInjection mais pas CSRF ? Assez courant en ce moment.

      De même les WYSIWYG (content editable) qu’il faut sécuriser car bourré de failles

      Et sinon ne pas stocker le mot de passe (si possible), les saler (pas comme LinkedIn) et utiliser du key stretching

      Répondre

      1. Pour les mots de passe, je préconisent de les hasher (avec un sel si possible) 😉

         Répondre