À la découverte de Security Code Scan
Les failles de sécurité, ça peut coûter cher. Non seulement si cela permet d‘extorquer de l’argent, mais aussi en terme d’image de marque. Du coup, comment être proactif face à cette menace ? Comment faire pour développer et déployer de nouvelles fonctionnalités au quotidien, tout en s’assurant de ne pas y glisser de nouvelles failles de sécurité ?
Bien que le risque zéro n’existe pas, il existe une multitude de réponses à cette question, qui sont autant de garde-fous qu’il est possible de mettre en place. Parmi ceux-ci, certains se sont imposés comme une évidence et sont généralisés dans nombre de sociétés, tels que l’application de règles de codage, le secure coding, la revue de code, l’écriture de tests automatisés, les sessions de recette… En tant qu’informaticiens, on a naturellement envie de limiter autant que possible les actions manuelles, qui sont coûteuses et sujettes à l’erreur, et d’automatiser tout ce qui peut l’être. On a aussi tendance à jeter un œil à ce qui existe déjà avant de réinventer la roue. C’est dans ce cadre que je me suis intéressé à Security Code Scan.
Présentation
Security Code Scan (SCS pour les intimes) est un analyseur de code pour .NET dont le but est de détecter des failles de sécurité potentielles. Si vous ne faites pas de .NET, libre à vous d’interrompre votre lecture pour m’insulter dans les commentaires pour vous avoir fait perdre 30 secondes de votre temps précieux, mais celles-ci ne seront pas remboursées. En même temps, ce billet vous aura peut-être permis de trouver des solutions similaires pour les technos qui vous sont chères, qui sait ?
SCS permet d'ajouter à l’écriture de code et à l’intégration continue un processus automatique et axé sécurité. Il s’agit d’un analyseur dit “statique” car ses règles sont appliquées sur le code source en dehors de toute exécution. On aimerait bien qu'il puisse automatiquement trouver toutes les failles de sécurité dans le code avec un très haut niveau de confiance, mais ce n'est bien sûr pas le cas. SCS est bien un outil d'aide au développeur dans sa quête d’écriture de code le plus sécurisé possible.
Ingénieuse lectrice, astucieux lecteur, tu te demandes certainement pourquoi j’ai choisi SCS plutôt qu’un autre autre outil du même type. Eh bien, c’est parce qu’il est gratuit, moderne (basé sur Roslyn) et en développement actif (j’ai remonté un petit bug, il a été corrigé le lendemain). Les autres outils que j’ai trouvés étant payants et moins souvent mis à jour, je me suis cantonné à SCS.
Bref, entrons dans le vif du sujet. SCS peut soit s’installer en tant qu’extension pour Visual Studio, soit via package NuGet. La deuxième option me semble globalement plus intéressante, du fait qu’elle nécessite une installation par projet plutôt que par poste développeur, qu’elle permet l’utilisation d’autres IDE que Visual Studio, et qu’elle s’intègre à tout serveur d’intégration continue supportant MSBuild. Elle a cependant quelques désavantages. Tout d’abord, il faut avoir la discipline d’installer le package NuGet partout où il peut être utile. Aussi, l’analyse du code ne se lance que pendant le build, tandis qu’elle a lieu en temps réel avec l’extension VS.
Installation
Testons SCS sur WebGoat.NET, un projet volontairement vulnérable mis à disposition par l’OWASP dans un but éducatif. Il existe deux packages NuGet de SCS : SecurityCodeScan et SecurityCodeScan.VS2017.
Comme leurs noms ne l’indiquent pas, le premier est en full .NET Framework, alors que le second est en .NET Standard. Préférez ce dernier, plus moderne, à condition qu’il soit compatible avec votre stack technique.
WebGoat ne contient qu’un seul projet, mais de manière générale, mieux vaut ne pas installer le package sur les projets de test, du fait qu’ils ne font pas partie du produit final, et risquent de faire inutilement gonfler le nombre de warnings. On parle alors de faux positifs. Par exemple, si l’on définissait un mot de passe en dur dans les tests, on se prendrait un warning “SCS0015 — Hardcoded Password” sans intérêt, avec SCS d’installé.
Une fois le package installé, à la construction de la solution, on obtient 30 warnings. On a aussi une erreur dont on va bientôt s’occuper. Parmi ces warnings, 29 sont générés par SCS (comme leur code l’indique : SCS0006, etc). Pour en savoir plus sur les différentes alertes que SCS remonte, référez-vous à la section “Rules” de la page Security Code Scan, qui vous guidera pour les corriger.
Configuration des règles
Faisons d’une pierre deux coups, en corrigeant l’erreur de compilation et en traitant un warning par la même occasion. Ça se passe dans la méthode SHA de la classe EncryptVSEncode.aspx.cs. À l’origine, elle ressemble à ça :
Ça ne compile pas car la variable locale “sha” est utilisée sans être forcément initialisée. C’est étrange qu’ils n’aient pas fait en sorte que la solution compile d’emblée, mais passons, on va rajouter un petit “default” dans le switch pour se débarrasser de cette erreur :
Maintenant, intéressons-nous au warning SCS que l’on a au niveau de l’initialisation de l’instance de SHA1Managed : “SCS0006 — Weak hashing function”. Disons, pour l’exercice, que l’on considère que ce warning est un faux positif que l’on souhaite désactiver. Pour ce faire, deux options s’offrent à nous : désactiver cette règle localement ou globalement. De manière générale :
- Optez pour la désactivation locale s’il s’agit d’une exception pour un cas précis. Exemple : désactiver la règle “SCS0006 — Weak hashing function” lorsque l’on hashe une donnée non sensible.
- Optez pour la désactivation globale s’il s’agit d’une règle inutile dans le cadre de tout un projet. Exemple : désactiver la règle “SCS0016 — Cross-Site Request Forgery (CSRF)” sur un projet d’API qui n’est pas lié à un front ASP.NET MVC.
Pour désactiver une règle localement, rien de nouveau. Soit on passe par une directive pragma, comme ceci :
Soit on passe par un fichier de suppression. Je préfère le pragma, plus simple et plus clair.
Pour désactiver une règle globalement (pour tout un projet), ça se passe dans References / Analyzers / SecurityCodeScan, en mettant la règle concernée sur “None” :
Cela va générer un fichier WebGoat.NET.ruleset dans le dossier du projet contenant tout le paramétrage personnalisé de vos règles :
Comme vous l’aurez sans doute remarqué, ce mécanisme ne permet pas seulement de désactiver des règles. On peut tout bonnement changer le niveau de sévérité de chacune des règles. Si l’on estime au contraire que la règle SCS0006 devrait générer des erreurs et non pas des warnings, il suffit de choisir la sévérité “Error”. Les warnings pouvant s’accumuler et passer sous le radar, paramétrer les règles en tant qu’erreurs peut-être une bonne façon d’empêcher les développeurs de les ignorer.
Conclusion
Pour conclure, récapitulons brièvement mes recommandations (qui ne sont pas universelles ou indiscutables, mais il faut bien faire des choix) :
- Garder sous le coude le glossaire des règles SCS
- Choisir le package NuGet SecurityCodeScan.VS2017
- L’installer sur tous les projets exceptés ceux de test
- Paramétrer toutes les règles en tant qu’erreur (ou le plus possible ; facile quand il s’agit d’un nouveau projet, plus difficile quand il s’agit de legacy)
- Désactiver localement les règles pour des cas exceptionnels (directive pragma)
- Désactiver globalement les règles qui ne sont pas pertinentes dans le cadre d’un projet (sévérité None)
Allez salut, et banzaï !
