Entretien avec Code Risk - Un service d'analyse de code source gratuit pour les plugins WordPress
Publié: 2018-10-17
D'un autre côté, de nombreux développeurs de plugins n'ont pas les ressources disponibles pour s'assurer que le code de leurs plugins est sécurisé, surtout s'il s'agit d'un petit plugin. Mais tout cela va changer, comme l'explique Hendrik Buchwald dans cette interview. Hendrik est ingénieur logiciel, chercheur en sécurité et co-fondateur de RIPS Technologies.
Que fait RIPS Technologies ?
RIPS Technologies est une entreprise de haute technologie basée à Bochum, en Allemagne. Nous fournissons une analyse de sécurité automatisée pour les applications PHP sous forme d'installation logicielle locale ou de service cloud hautement évolutif. Nos algorithmes d'analyse de code innovants, spécifiquement dédiés au langage PHP, peuvent identifier les vulnérabilités de sécurité complexes dans les applications modernes comme aucune autre solution. Notre mission est de fournir aux développeurs et aux professionnels de la sécurité l'analyse de sécurité la plus précise et la plus efficace possible.
Selon vous, quelle est l'erreur de sécurité la plus courante commise par les développeurs et quelles sont les 3 principales vulnérabilités que vous voyez dans les plugins WordPress ?
Sans surprise, les problèmes les plus courants sont les vulnérabilités de script intersite (XSS) qui se produisent chaque fois que l'entrée de l'utilisateur est imprimée sans nettoyage approprié sur la page de réponse HTML. D'une part, ces problèmes apparaissent fréquemment car la sortie de données est l'opération la plus courante des applications PHP et donc plus affectée par les violations de sécurité que les autres opérations. Et deuxièmement, étant donné la diversité des contextes HTML et ses pièges dans la désinfection, ces problèmes sont facilement introduits. Les vulnérabilités de cross-site scripting (XSS) sont assez sérieuses dans WordPress car elles peuvent être utilisées, par exemple, pour injecter du code PHP via l'éditeur de template. Heureusement, ils nécessitent cependant une interaction avec un administrateur.
Les deuxièmes problèmes les plus courants sont les vulnérabilités d'injection SQL. Les injections SQL sont plus graves que les vulnérabilités de script intersite car, dans le pire des cas, elles peuvent être utilisées pour extraire des informations sensibles de la base de données - par exemple des mots de passe - sans aucune interaction de l'utilisateur. En conséquence, ils peuvent être utilisés pour des attaques malveillantes entièrement automatisées.
Dans quelle mesure diriez-vous que la sécurité globale des 1 000 plugins les plus populaires/téléchargés est bonne ou mauvaise ?
Il est difficile de répondre car je n'ai pas examiné en détail les 1 000 plugins les plus populaires. De telles opérations prendraient plusieurs mois, et le temps que nous soyons prêts, nous devions recommencer car certains plugins sont mis à jour très fréquemment.
D'où l'importance d'utiliser un service de sécurité automatisé tel que Code Risk. Bien que d'après le score CodeRisk, qui est généré à partir des analyses de code source automatisées et non vérifiées que nous effectuons sur le référentiel, je peux dire que le code de la plupart n'est pas mauvais, bien qu'il existe également des plugins avec un mauvais score. La plupart de ces plugins sont très volumineux et ont beaucoup de fonctionnalités. Cela augmente automatiquement les chances d'avoir un bogue quelque part. D'après nos tests manuels, nous pouvons également dire que les gros plugins ont souvent des vulnérabilités logiques.
Pouvez-vous nous en dire un peu plus sur ce que vous proposez aux développeurs de plugins WordPress ?
Notre dernier projet CodeRisk aide les développeurs et les utilisateurs à évaluer gratuitement le risque de sécurité du code de leur plugin. Pour l'instant, cela se limite aux plugins WordPress hébergés dans le référentiel WordPress officiel.
Nous récupérons automatiquement les nouveaux plugins du référentiel WordPress et les analysons avec notre scanner de sécurité PHP RIPS. Les résultats détaillés du RIPS sont combinés en une valeur de risque facile à comprendre. La valeur prend en compte la gravité de l'exploitation réussie, la quantité de problèmes trouvés par rapport à la taille du code et la probabilité qu'un problème puisse être abusé par un tiers.
Les développeurs de plugins peuvent demander les résultats détaillés complets pour leurs propres plugins via un système automatisé. Ils peuvent utiliser les informations pour corriger d'éventuelles vulnérabilités et renforcer leur code, rendant ainsi l'écosystème WordPress plus sécurisé. L'idée derrière CodeRisk est de permettre aux développeurs de plugins de trouver eux-mêmes les problèmes dans leur code, même s'ils ne sont pas avertis en matière de sécurité. Bien que nous fassions de nombreuses recherches sur la sécurité de WordPress et que nous signalions de nombreuses vulnérabilités aux développeurs, il existe beaucoup trop de plugins pour les analyser tous manuellement.
De nombreux développeurs de plugins s'abonnent-ils et utilisent-ils votre service gratuit d'analyse de code source ? Quelle est la réponse de la communauté WordPress ?
Actuellement, il existe quelques dizaines de développeurs de plugins qui utilisent CodeRisk pour réduire le risque de failles de sécurité dans leurs plugins. Nous avons reçu beaucoup de bons retours jusqu'à présent et CodeRisk a déjà aidé à résoudre des centaines de problèmes.
Les scanners automatisés ont tendance à signaler les faux positifs et les cas extrêmes qui pourraient ne pas être exploitables. Étant donné que de nombreux développeurs ne sont pas avertis en matière de sécurité, que faites-vous pour les aider et éviter les fausses alertes ?
Nos utilisateurs doivent être conscients que nous mettons en évidence le code qui présente un risque de sécurité. Parmi les vulnérabilités de sécurité involontaires, cela inclut également d'autres découvertes, par exemple des protections faibles qui peuvent devenir une menace plus tard.
Vous n'avez pas besoin de savoir si et comment un problème est exploitable pour vous assurer qu'il ne deviendra pas une menace pour la sécurité à l'avenir. Par exemple, si vous imprimez la valeur de retour d'une fonction, assurez-vous de l'encoder correctement pour éviter les vulnérabilités de script intersite. Même si la valeur de retour ne contient pas encore d'entrée utilisateur, cela pourrait ne plus être le cas à l'avenir.
Où voyez-vous ce projet WordPress gratuit aller ? Avez-vous des plans pour cela? Peut-être offrir un service premium aux développeurs, les aider à comprendre les résultats et à en tirer le meilleur parti ?
La prochaine version de CodeRisk ajoutera la prise en charge des thèmes WordPress car ils font partie intégrante de la plupart des blogs et contiennent souvent également des vulnérabilités. À un moment donné, nous aimerions étendre CodeRisk à d'autres systèmes de gestion de contenu. Il n'y a actuellement aucun plan pour un service premium, mais si la demande est suffisante, cela pourrait changer.
Pouvez-vous donner aux développeurs WordPress deux ou trois bonnes pratiques de développement sécurisé à suivre afin qu'ils puissent écrire du code plus sécurisé ?
Si vous voulez écrire du code plus sécurisé, ne faites jamais aveuglément confiance au code existant. Supposez toujours que les fonctions peuvent renvoyer une entrée utilisateur et traitez-les comme telles. Pour des informations générales sur la façon d'écrire du code PHP sécurisé, consultez le Guide 2018 pour créer un logiciel PHP sécurisé.
Visitez le site Web de CodeRisk pour plus d'informations sur le service. Et si vous êtes un développeur de plugins WordPress et que votre plugin est sur le référentiel de plugins WordPress, inscrivez-vous pour un compte gratuit pour voir quelles vulnérabilités votre plugin pourrait avoir.