Oui, le développeur a un rôle important à jouer. Malheureusement, on le sous-estime trop souvent : soit par désintérêt, soit par manque de temps pour le réaliser convenablement. Les bonnes pratiques, les règles de codages sont là pour « blinder » le code.
Bien entendu, le développeur n’est qu’un des éléments de la chaîne de sécurité. Car au-delà du code, si les serveurs où sont déployés les apps, ne sont pas à jour (par exemple : une pile LAMP non patchée ou les sécurités non appliquées), le code aura beau être propre, les failles seront là.
Ce n’est pas un hasard, si on répète mois après mois :
- Mettre à jour les serveurs et les modules avec les dernières versions et surtout les patchs de sécurité
- Ne pas utiliser en production des versions en fin de support ou obsolètes. Par exemple, PHP 5.6 et 7.0 arriveront en fin de support (actif et de sécurité) les 3 et 31 décembre 2018. Continuer à utiliser ces briques au-delà de cette date, c’est avoir une faille potentielle !
OWASP Top 10 : un indicateur imparfait mais utile !
OWASP (Open web Application Security Project) fournit des bonnes pratiques et un état des lieux de la sécurité dans le développement web, mobile, IoT, etc. Le top 10 des risques de sécurité des applications web est toujours savoureux (ou consternant).
Car finalement, de nombreuses failles présentées dans le top 2017 (la version 2018 n’était pas encore disponible à écrire de cet article) existent depuis de (très) nombreuses années. A croire, que l’on n’apprend jamais rien, ou lentement. Entre 2013 et 2017, 3 nouvelles failles ont les honneurs du top 10, 2 ont fusionné en une, et le reste, était déjà là en 2013.
En 1ere place, nous retrouvons une de mes failles préférées : l’injection (de code). L’injection de codes est un des grands classiques des vulnérabilités et des attaques. Il s’agit d’introduire du code malveillant ou des données non conformes (par exemple via un formulaire, un champ de saisie).
Ces données peuvent être ensuite directement reprises par les requêtes et la base de données. Les classiques de l’injection concernent : SQL, commandes systèmes, LDAP, ORM. Durant ma vie de développeur – testeur, il y a presque 25 ans, on m’en parlait déjà et c’était même une des failles prioritaires à détecter.
Je passais une partie de mes tests de non-régression à repérer les possibilités d’injection, car entre deux releases, les développeurs pouvaient modifier des paramètres impactant le comportement de l’objet.
Et pourtant ce n’est pas comme si, on ne pouvait rien y faire. Les outils et les méthodes pour détecter cette faille existent : revue de codes, scan automatisé de tous les champs, mise en place d’une white list input validation, mise en place d’un contrôle du code SQL et des requêtes.
Les autres failles :
- Violation de gestion d’authentification et de session
- Exposition de données sensibles
- XML ExternalEntity (XXE)
- Contrôle d’accès cassé
- Mauvaise configuration de sécurité
- Cross Site Scripting (XSS)
- Desérialisation non sécurisé
- Utilisation de composants avec des vulnérabilités connues
- Gestion de log insuffisante et de monitoring
OWASP propose même une liste d’actions proactives durant la phase de programmation :
- Vérifier la sécurité le plus tôt possible et régulièrement
- Paramétrer les requêtes
- Encoder les données et éviter de laisser des données critiques en claires ou en dur dans le code (non, on ne rigole, cela se fait encore)
- Valider toutes les entrées
- Implémenter des contrôles d’identification et d’authentification
- Mettre en œuvre les bons contrôles d’accès
- Protéger les données (en complément au 3)
- Implémenter les logs (et ne pas oublier de les consulter) et la détection d’intrusion
- Utiliser les frameworks de sécurité disponibles dans le langage utilisé
- Avoir une bonne gestion des erreurs et des exceptions
Soyons clairs : un code non sécurisé à la conception sera plus difficile et plus long à sécuriser, car il faudra reprendre l’ensemble du code. Même remarque pour du code legacy non sécurisé ou encore un code dont la documentation technique n’existe pas ou n’est pas à jour ! Le développeur perdra énormément de temps.
La sécurité est un des enjeux des méthodes agiles, par exemple dans Scrum avec l’usage des tests unitaires (la base) dans l’intégration continue (phase de validation durant le build). DevOps est de plus en plus sensible à cette démarche avec le DevSecOps.
Même si la situation s’améliore, les pressions pour tenir les délais (parfois irréalistes), les mauvaises pratiques ou tout simplement le manque de sensibilisation et de formations nuisent à la qualité du code et par conséquent à la sécurité.
La sécurité par design nécessite plus de temps, notamment pour mettre en place les tests et utiliser les bons outils. L’intégration continue, l’usage systématique des règles de codage, sont des étapes dans le secure by design.
Source : Cette information et actualité qui a suscité notre intérêt, a été publiée sur le site zdnet.fr que nous remercions. il nous a semblé pertinent de vous en faire profiter.
