La plupart des développeurs s'accordent sur la nécessité d'écrire du code sécurisé, mais ils constatent souvent que la pression de livrer quelque chose limite leur capacité à le faire. D'autres ne savent peut être tout simplement pas par où commencer. Dans les deux cas, avoir établi un guide peut s'avérer utile pour l'amélioration de leur approche.
InfoQ a eu l'opportunité d'échanger avec les auteurs de Java Coding Guidelines pour parler de la façon dont leur nouveau livre aide les développeurs à écrire un meilleur code et fournit un guide pour savoir quoi chercher.
InfoQ : Beaucoup de développeurs voudraient améliorer la qualité de leur code du point de vue sécuritaire, mais ne savent pas par où commencer. D'autre pensent qu'ils sont bons en théorie, mais sont coincés par la base d'un code existant. Que diriez-vous à ces programmeurs qui en arrivent tous au même point mais au travers de situations différentes ?
Auteurs : La façon dont vous utilisez ce livre dépend fortement de ce que vous faites. Si vous êtes au prélude d'un développement logiciel en Java, vous voudrez d'abord le parcourir au moins une fois de façon succincte pour vous imprégner de l'essentiel des lignes directrices. Ensuite, quand vous commencez à développer votre système, vous pouvez revenir en arrière et revoir les directives propres à une question qui se pose et à son application.
D'un autre côté, si vous maintenez un système existant, vous voudrez plutôt examiner les lignes directrices jusqu'à ce que vous trouviez celle qui est "spéciale", examiner votre code pour vérifier si le problème est présent, puis vous reporter à cette ligne directrice comme stratégie d'optimisation.
InfoQ : Quand on regarde le livre, il est divisé en contenus sur la sécurité, la programmation défensive, la robustesse, la lisibilité du programme et les idées fausses des programmeurs. Parmi tous ces thèmes, quel est selon vous celui sur lequel il faut mettre le plus l'accent ?
Auteurs : L'objectif principal de Java Coding Guidelines est d'aider les programmeurs à faire des choix intelligents dans un contexte d'incertitude sur l'application de certains concepts de programmation, de conception ou sur les caractéristiques du langage. Les idées fausses des programmeurs abordent la question spécifique "Quels sont les malentendus communs?" La lisibilité du programme décrit le long chemin permettant de s'assurer que le code est sans ambiguïtés et par conséquent, plus facile à maintenir. Les chapitres sur La sécurité, la programmation défensive et la robustesse inculquent la nécessité de fournir des systèmes robustes, résistants aux attaques et aux erreurs.
InfoQ : De quelle manière votre livre fait-il référence à The CERT Oracle Secure Coding Standard for Java ? Faut-il utiliser le guide après avoir lu ce livre ou en même temps ?**
Auteurs : The CERT Oracle Secure Coding Standard for Java définit des règles pour le codage sécurisé en Java qui, si elles ne sont pas respectées, peuvent entraîner des vulnérabilités exploitables. Java Coding Guidelines contient des recommandations qui, de manière générale, améliorent la sécurité et la fiabilité du logiciel, bien que toute violation de celles-ci n'impliquera pas automatiquement l'existence d'un défaut dans le code. Il est mieux d'utiliser les deux livres ensembles, car ils fournissent des conseils indépendants, et vous n'y trouverez que peu, voir pas de redondances entre les deux. La plupart des recommandations énoncent des principes généraux de programmation à respecter, alors que la norme énumère les erreurs à éviter. Java Coding Guidelines contient des références à The CERT Oracle Secure Coding Standard for Java mais a été rédigé de manière à être autonome.
InfoQ : Jusqu'à quel degré les outils existants scannent automatiquement le code pour ce type d'erreurs ? Est-ce qu'un outil automatique peut remplacer la nécessité pour un programmeur d'être familier avec ces concepts ?
Auteurs : Les programmeurs doivent se familiariser avec les concepts de Java Coding Guidelines parce qu'il est plus simple d'éviter d'introduire des défauts et des vulnérabilités dans le code pendant le développement, que de les trouver et de les corriger pendant les tests, ou pire, pendant le déploiement. La plupart des analyses existantes manquent de pertinence et sont incomplètes, ce qui veut dire qu'elles peuvent entraîner des faux négatifs et respectivement, des faux positifs. Les développeurs doivent donc être en mesure de déterminer si un diagnostic émis par un outil respecte ou non les règles, et également d'éviter ou d'éliminer des violations qui n'ont pas été diagnostiquées. CERT (Computer Emergency Response Team) a créé le Source Code Analysis Laboratory (SCALe), qui utilise une variété d'analyseurs statiques pour évaluer le code et le respect des règles de programmation en matière de sécurité. Plusieurs de ces outils n'ont pas de capacités pour la redondance, il est donc nécessaire d'utiliser un certain nombre d'outils pour obtenir une couverture large. Le processus SCALe n'est que partiellement automatisé; les analystes ont toujours besoins d'examiner les diagnostics pour éliminer les faux positifs.
InfoQ : Rencontrez-vous des équipes désignant "un monsieur sécurité" ? L'ensemble de l'équipe doit-elle rester au point sur les questions de sécurité ?
Auteurs : C'est beaucoup mieux quand toute l'équipe comprend la programmation sécurisée. Toutes les personnes qui développent ont besoin de savoir comment le faire de manière sécurisée, car le meilleur moment pour obtenir un code bon, c'est pendant son écriture. Si une personne de l'équipe a reçu une formation supplémentaire pour la sécurité, cette information peut être diffusée de manière efficace à travers des revues de code et des audits de sécurité. Les équipes de développement doivent s'engager à développer un code conforme, pour cela les livres peuvent servir de référence. Les développeurs peuvent également suivre et/ou participer à l'évolution de nos normes sur www.securecoding.cert.org, grâce à notre newsletter et notre forum Secure Coding sur LinkedIn.
InfoQ : Existe-t-il une erreur en particulier que vous voyez fréquemment se répéter ?
Auteurs : Il y a des erreurs qui reviennent fréquemment en Java parce que le langage offre une grande souplesse pour la conception. Par exemple, la règle de sécurité ERR-08-J Do not catch NullPointerException or any of its ancestors n'est souvent pas respectée car il y a tentative de contournement des dispositifs de gestion des exceptions prévus par Java. Un trop large éventail de déclarations catch ou throw dans le code se traduit souvent par des erreurs étant passées sous silence. La gestion des exceptions reste un domaine difficile parce que beaucoup d'applications Java et de frameworks web placent la responsabilité de la gestion des exceptions et des sources d'erreurs dans les mains du développeur. CERT analyse des logiciels Java pour vérifier la conformité à The CERT Oracle Secure Coding Standard for Java. Les principales violations de règles que nous avons détecté sont les suivantes:
A. EXP01-J. Never dereference null pointers
B. ERR01-J. Do not allow exceptions to expose sensitive information
C. ERR07-J. Do not throw RuntimeException, Exception, or Throwable
D. ERR08-J. Do not catch NullPointerException or any of its ancestors
E. FIO04-J. Release resources when they are no longer needed
F. ERR00-J. Do not suppress or ignore checked exceptions
A propos des auteurs
Fred Long est Maître de conférences et Directeur du département Learning and Teaching de l'Université d'Aberystwyth et Visiting Scientist de SEI (Software Enginnering Institute).
Dhruv Mohindra est Responsable technique au sein du groupe Security Practices qui fait partie du bureau du CTO (Chief Technology Officer) au Persistent Systems Limited, India, où il fournit des informations en tant que consultant sur des solutions dans divers secteurs de technologies transverses.
Robert C. Seacord gère le Secure Coding Initiative du CERT, et est Professeur à la School of Computer Science du CMU (Carnegie Mellon University).
Dean F. Sutherland, Senior Software Security Researcher au CERT, a passé 14 ans comme Ingénieur logiciel à Tartan, Inc.
David Svoboda, Software Security Engineer du CERT, a été le principal développeur de plusieurs projets de développement de la CMU depuis 1991.