La Quete du code source fiable et sécurisé - GSDAYS 2015
1 j'aime•4,186 vues
Le document aborde l'analyse du code source en mettant en lumière les enjeux de maintenabilité, fiabilité et sécurité, avec un accent sur les défauts automatiques détectables. Il présente des stratégies méthodologiques, en particulier l'utilisation de SonarQube pour intégrer des règles de codage sécurisées et améliorer le développement logiciel. La collaboration entre OWASP et SonarSource est mise en avant pour créer des outils et règles d'analyse de sécurité efficaces.
La Quete du code source fiable et sécurisé - GSDAYS 2015
- 1. Par Sébas)en Gioria et Freddy Mallet La quête du code source maintenable, fiable et sécurisé
- 2. Sébas7en Gioria • h:p://www.google.fr/#q=sebas7en gioria • Innova7on and Technology @Advens && Applica7on Security Expert • OWASP France Leader & Founder & Evangelist, OWASP ISO Project & OWASP SonarQube Project Leader • Applica7on Security group leader for the CLUSIF • Proud father of youngs kids trying to hack my digital life. @Spoint et @OWASP_France [email protected]
- 3. Freddy Mallet • Créateur de la plateforme SonarQube • Co-‐fondateur de la société SonarSource • @FreddyMallet • [email protected]
- 4. Agenda • Enjeux autour de l’analyse du code source • Tout ce que le code source peut dire • Mise en œuvre méthodologique • SonarQube / projet OWASP / Demo 4
- 5. Enjeux autour de l’analyse du code source
- 6. Enjeux autour de l’analyse du code source
- 7. Beaucoup de défauts pouvant conduire à des problèmes de maintenabilité, de stabilité et de sécurité peuvent être détectés automa7quement. Et tout par7culièrement les plus sournois
- 8. Approche boîte noire VS boîte blanche Top10 Web Tests d’intrusion Analyse du code A1 -‐ Injec7on ++ +++ A2 – Viola7on de Session / Authen7fica7on ++ + A3 – Cross Site Scrip7ng +++ +++ A4 – Références Directes + +++ A5 – Mauvaise configura7on + ++ A6 – Exposi7on de données ++ + A7 – Probleme d’habilita7on fonc7onnelle + + A8 -‐ CSRF ++ + A9 – U7lisa7on de Composants vulnérables +++ A10 – Redirec7on et transferts + +
- 9. L’ analyse de code ou le test d’intrusion du point de vue du développeur ?
- 10. L’évolu7on du développement logiciel Vi / Emacs Makefile Version Control Building Tools Ticket Tracking Continuous Integration Refactoring From the IDE Unit Tests Continuous Inspection
- 11. Tout ce que le code source peut dire
- 12. Les principaux types de défauts Maintenabilité ??? Fiabilité Multi-threadings, null pointers, buffer overflows, unclosed resources, … Sécurité OWASP Top 10, SANS TOP 25, …
- 13. Exemples liés à la sécurité • Injec7on SQL, LDAP, … • Login/mot de passe en dur • U7lisa7on d’algorithmes de hashage trop faibles: MD5, SHA1, … • Injec7on de code • Redirec7on web vers un site inconnu • …
- 14. Exemples liés à la fiabilité • Déréférencement de pointeurs null • Débordement d’en7er • Condi7ons invalides • Assigna7on d’une variable à elle même • Ressources non libérées • Assigna7on d’une valeur jamais u7lisée • …
- 15. Quid de la maintenabilité ? • ? • ? • ? • ? • ? • ?
- 16. Duplica7on de code Que choisir entre la peste et le choléra ?
- 17. Mauvaise distribu7on de la complexité Vaut-‐il mieux une méthode d’une complexité de 30 ou 10 méthodes d’une complexité de 3 ?
- 18. Pas ou peu de tests unitaires
- 19. Mauvais Design Quel classe/package est responsable de quoi ?
- 20. Non respect des standards Comme par exemple la stratégie de ges7on des excep7ons
- 21. Pas ou peu de commentaires Ce:e expression régulière “match” quoi par exemple ?
- 22. Quid de la maintenabilité • Duplica7on de code • Mauvaise distribu7on de la complexité • Peu ou pas de tests unitaires • Mauvais design • Non respect des standards • Pas ou peu de commentaires
- 23. Mise en oeuvre méthodologique
- 24. Approche tradi7onnelle • Retour trop tardif • Manque d’implica)on des développeurs • Pushback de ces derniers • Pas de réelle douane applica7ve • Ou)ls, processus et personnes différentes pour chasser les différents types de défauts
- 25. Comment rembourser la de:e ? • Le montant total peut être déprimant • Faut-‐il demander un budget dédié ? • Le risque d’injec)on d’une régression fonc)onnelle existe • Ce n’est pas très “fun” !
- 26. Ce qu’il faut changer • La boucle de rétroac7on doit être beaucoup plus rapide • Une douane applica7ve non négociable doit exister • Les développeurs doivent être au coeur du processus • Le coût doit être non significa7f • L’approche doit être unifiée
- 27. Se focaliser sur la fuite
- 30. SonarQube • Intégrable dans la chaine de build • Support de nombreux languages: C/C++, Java, PHP, JavaScript, COBOL, C#, PL/SQL, … • Support du concept de douane applica7ve • Extensible: nombreux plugins • Ges7on temporelle des défauts • Open-‐Source
- 31. SonarQube pour la sécurité applica7ve • S’intègre dans le SDLC – liens possible avec Jenkins/Hudson/Bamboo – Repor7ng sur les défauts – Possibilité d’ajouter des règles (en XPath) • Dispose de règles perme:ant de couvrir – non respect des regles de codage – découverte de bugs sécurité(XSS, SQl-‐Injec7on)
- 32. SonarQube pour la sécurité applica7ve • Ce n’est pas un ou7l de revue de code ! – Il fonc7onne sur la viola7on de règles; détec7on de pa:erns uniquement • Il 7re toute sa puissance – si vous disposez d’une poli7que de Secure Coding – si vous démarrer un nouveau projet • Il n’est pas “tres” orienté sécurité actuellement – peu de plugins de sécurité – pas de profils type pour les viola7ons de secure coding.
- 33. Le projet OWASP SonarQube • Collabora7on OWASP / SonarSource – Me:re a disposi7on de la communauté un ensemble de règles, profils, et plugins pour analyser la sécurité avec SonarQube. • Plusieurs objec7fs prévus – Lier les règles au référen7el MITRE CWE – Tagguers les règles suivant les catégories OWASP Top 10 2013 – Développement de nouvelles règles “sécurité” – Nouveau widget pour offrir une perspec7ve “sécurité” sur le code source – Etendre ces objec7fs à tous les plugins langage