Chapitre 9. Meilleures pratiques de sécurité pour les développeurs

Les développeurs qui empaquettent des logiciels devraient faire de leur mieux pour s'assurer que l'installation du logiciel, ou son utilisation, n'introduit pas de risques en matière de sécurité à la fois au système où il est installé et à ses utilisateurs.

Pour ce faire, ils devraient faire de leur mieux pour examiner le code source du paquet et détecter tous les défauts qui pourraient introduire des bogues de sécurité avant de publier le programme ou de distribuer une nouvelle version. Il est reconnu que le coût de correction de bogues augmente aux différentes étapes de son développement, il est donc plus facile (et moins coûteux) de corriger les bogues lors de la conception qu'une fois le logiciel déployé et en mode maintenance (plusieurs études disent que le coût dans cette dernière phase est soixante fois plus élevé). Bien que plusieurs outils essayent de détecter automatiquement ces défauts, les développeurs devraient faire leur possible pour se tenir au courant des différents types de défauts de sécurité afin de les comprendre et être capable de les remarquer dans le code qu'ils (ou d'autres) ont écrit.

Parmi les bogues de programmation qui conduisent à des bogues de sécurité, les plus typiques sont les http://fr.wikipedia.org/wiki/Dépassement_de_tampon, les dépassements de chaîne de formatage, les dépassements de tas et les dépassements d'entier (dans les programmes en C ou C++), les http://en.wikipedia.org/wiki/Symlink_race temporaires (dans les scripts), les http://en.wikipedia.org/wiki/Directory_traversal et les injections de commande (sur les serveurs) et http://fr.wikipedia.org/wiki/Cross-site_scripting, et les http://fr.wikipedia.org/wiki/Injection_SQL (dans le cas des applications orientées web). Pour de plus amples renseignements sur les bogues de sécurité, consultez la https://www.fortify.com/vulncat/en/vulncat/index.html de Fortify.

Certains de ces problèmes pourraient ne pas être faciles à repérer à moins d'être un expert dans le langage de programmation utilisé par le logiciel, mais certains problèmes sont faciles à détecter et à corriger. Par exemple, trouver des conditions de situation de compétitions temporaires à cause d'une mauvaise utilisation de répertoires temporaires peut se faire facilement en exécutant « grep -r "/tmp/" . ». Ces appels peuvent être examinés et les noms de fichiers écrits en dur, utilisant des répertoires temporaires, remplacés par des appels à mktemp ou tempfile dans les scripts d'interpréteur, File::Temp(3perl) dans les scripts Perl ou tmpfile(3) en C ou C++.

Certains outils permettent d'aider à l'examen de sécurité du code, comme rats, flawfinder et pscan. Pour de plus amples renseignements, consultez la http://www.debian.org/security/audit/tools.

Lors de l'empaquetage, les développeurs de logiciel doivent s'assurer de suivre les principes de sécurité habituels, y compris :

Si vous devez faire l'un des deux, assurez-vous que les programmes qui pourraient s'exécuter avec des privilèges plus élevés ont été contrôlés pour les bogues de sécurité. En cas de doute, ou pour obtenir de l'aide, contactez l'http://www.debian.org/security/audit/. Pour les binaires setuid ou setgid, suivez la section de la charte Debian sur les http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners.

Pour de plus amples renseignements, spécifiques à la programmation sécurisée, assurez vous de lire (ou d'indiquer en amont) le http://www.dwheeler.com/secure-programs/ et le portail https://buildsecurityin.us-cert.gov/portal/.