Comment faire face à ce problème fondamental avec les conseils: "Ne faites pas confiance aux bibliothèques obscures PHP que personne n'utilise!"?
Souvent, je dirais que dans pratiquement tous les cas , il n'y a qu'une seule bibliothèque PHP pour un problème particulier. ( Je ne compte pas ceux qui sont obsolètes, abandonnés ou non.)
Par conséquent, ce n'est jamais un "choix" de ma part de l'utiliser. Je ai pour l'utiliser ou rien.
Pour cette simple raison, le conseil de sécurité sonore de "ne pas utiliser de bibliothèques obscures non promues ou utilisées par beaucoup de gens et de grandes entreprises" est rarement applicable, car il n'y a tout simplement pas d'alternative à choisir!
Et c'est pour [~ # ~] php [~ # ~] - l'un des plus populaires/plus grands/les langages de programmation actuels les plus utilisés sur la planète. Imaginez si j'utilisais un langage beaucoup moins populaire; Je ne trouverais jamais de bibliothèque pour faire quoi que ce soit!
Il semble que ce conseil ne fonctionne qu'en théorie. En réalité, il y a très peu, voire pas, de choix entre les bibliothèques et même les langues, sauf si vous allez tout faire par vous-même, à partir de zéro. (Ou peut-être si vous pouvez payer de l'argent, ce que je ne peux pas, et donc je n'ai même jamais envisagé d'alternatives payantes potentiellement existantes.)
La raison pour laquelle je pose cette question est que je le reçois toujours comme l'un des principaux conseils pour rester en sécurité et ne pas obtenir de logiciels malveillants via les bibliothèques compromises/malveillantes PHP PHP. Cependant, quand il y a juste une chose à choisir, par exemple "MailMimeParser", ce qui semble presque toujours être le cas (avec toutes les "alternatives" ayant des arrêts majeurs comme être mort ou tout simplement ne pas fonctionner comme annoncé), que puis-je faire d'autre?
Vous dites que vous n'avez pas le choix, mais ce n'est pas vrai. Vous pouvez écrire vous-même tout le code dont vous avez besoin. Ou vous pourriez payer un professionnel de confiance pour écrire le code pour vous. Ou vous pourriez payer une entreprise de sécurité pour auditer le code avant de l'utiliser. Ou vous pouvez accepter le risque et mettre en œuvre d'autres contrôles de sécurité pour atténuer les risques. Par exemple, si vous craignez qu'un code ne soit vulnérable à l'injection SQL, vous pouvez configurer un WAF (Web Application Firewall) en face.
La sécurité a un coût: temps, ressources, expertise, argent. Il n'y a pas de déjeuner gratuit. Si vous ne pouvez pas vous le permettre, vous devrez soit éviter le problème (repenser votre projet), soit le déléguer (quelqu'un d'autre s'en occupera), soit l'atténuer (par exemple avec une défense en profondeur) ou simplement accepter le risque de vous faire pirater.
Personnellement, dans votre cas, lorsque vous devez gérer du code peu utilisé, si la bibliothèque n'est pas trop grande, j'essayerais de lire le code, au moins pour vérifier s'il y a une "odeur de code". Même si vous ne vérifiez pas toute la logique, il est facile de vérifier s'il y a suffisamment de commentaires, s'ils ont un sens, si le code est propre et compréhensible, si certaines fonctions sont utilisées conformément aux meilleures pratiques, s'il y a des vérifications sur le données d'entrée, etc. Le risque que le code soit utilisé par seulement quelques personnes et maintenu par seulement quelques développeurs est également qu'il pourrait cesser d'être maintenu, ou que la maintenance s'avère de toute façon trop lente, donc à la fin de la journée, vous pourriez être obligé de lire et de comprendre le code de toute façon, pour réparer votre application.Ensuite, si possible, j'essayerais également d'implémenter quelque chose pour la défense en profondeur, bien que la configuration correcte d'un WAF puisse ne pas être facile, si vous voulez vraiment qu'il soit efficace et en même temps, évitez de casser votre application à cause de faux positifs.
Je vais d'abord aborder la partie générique de votre question, puis la partie spécifique PHP.
Ne faites pas confiance aux bibliothèques obscures PHP que personne n'utilise!
C'est juste la question habituelle de gain/risque. Si le risque est faible, vous pouvez tout faire et utiliser des bibliothèques obscures (voire cassées). Cela signifie que ni la plate-forme ni le résultat de l'application finale ne sont essentiels à la mission. S'il échoue à un moment, il vous suffira de produire un correctif ou de trouver une solution de contournement.
Si vous souhaitez inclure la bibliothèque dans une application à valeur ajoutée, vous avez besoin d'une évaluation du risque que la bibliothèque ne se comporte pas exactement comme prévu. La manière la plus courante est (comme dans Stack Exchange) la réputation . Si la bibliothèque est connue pour avoir été largement testée et est toujours maintenue, le risque de tomber dans un cas d'angle non testé est faible et vous pouvez espérer que si vous remarquez un problème, il sera corrigé. Si elle est juste maintenue occasionnellement et a peu d'utilisateurs, vous (ou vos utilisateurs) pourriez tomber plus tard dans un tel cas de coin et n'avoir aucun meilleur moyen que de documenter que l'application votre ne peut tout simplement pas faire cela.
Si la réputation n'est pas bien établie, vous pouvez essayer de creuser un peu dans le code. S'il semble bien structuré, bien documenté et contient des tests, vous pouvez au moins faire confiance au respect des règles de bonnes pratiques. En guise de point secondaire, les tests montreront sur quel cas d'utilisation la bibliothèque se concentre.
Si la bibliothèque ressemble vraiment à une obscure , et que vous souhaitez l'utiliser, vous devrez tester non seulement votre propre code, mais aussi le tester. la bibliothèque se comporte comme prévu pour tous les cas d'utilisation que vous souhaitez que votre application accepte. Parce que vous ne pouvez pas lui faire confiance aveuglément. Mais si vous le faites sérieusement, cela prendra du temps.
PHP vs langages moins utilisés
PHP est probablement le langage le plus utilisé pour les programmeurs non professionnels. Cela signifie que si vous avez besoin de quelque chose, quelqu'un d'autre l'a déjà produit. Mais vous ne pouvez pas être sûr de la qualité. Java est beaucoup moins utilisé en dehors des produits de qualité professionnelle. Mais de nombreuses bibliothèques sont produites par de grandes organisations bien connues et fortement testées. Quand je reçois quelque chose des projets Spring, je suis convaincu qu'il a mieux suivi règles de pratique et ont été largement testés.
Seulement mon avis mais c'est une des raisons pour lesquelles j'hésite à utiliser PHP code: il y a plein de PHP code autour, certains très sympa) qualité, mais le risque d'obtenir un morceau de code de mauvaise qualité est élevé.
Le conseil est essentiellement une cartographie des principes de confiance que l'on a dans le monde "réel" dans le monde du développement logiciel:
- Ne faites pas aveuglément confiance à quelqu'un, mais vérifiez sa réputation. Il vaut mieux faire confiance à quelqu'un qui a également déjà fait confiance depuis un certain temps à beaucoup d'autres, car dans ce cas, il est moins probable que la confiance soit abusée. Pour le développement de logiciels, cela signifie utiliser des bibliothèques qui sont également utilisées par d'autres et qui ont une bonne réputation.
- Et si vous devez traiter avec quelqu'un qui n'a pas de réputation établie, soyez très prudent. En cas de développement logiciel, cela signifie de vérifier que le code fait réellement ce qu'il est censé faire et rien de plus (c'est-à-dire pas de portes dérobées, pas de bogues critiques).
Si vous ne suivez pas ces simples règles du monde réel dans le développement de logiciels, vous pouvez vous graver de la même manière que vous pouvez le faire dans la vie réelle: quelqu'un pourrait abuser de la confiance (non fondée) que vous avez, ce qui pourrait par exemple entraîner une porte dérobée ou un bug critique dans votre logiciel. Et cela pourrait également nuire à votre propre réputation.
Bien sûr, il est toujours possible que quelqu'un ait une bonne réputation et abuse encore de la confiance. Et il y a suffisamment d'exemples où cela se fait. Mais c'est beaucoup moins probable par rapport à quelqu'un sans réputation, car il faut beaucoup d'efforts pour se bâtir une bonne réputation en premier lieu. Par rapport à cela, une bonne réputation peut être facilement et rapidement perdue si elle est mal utilisée, de sorte que la plupart n'essayeront pas d'abuser de leur bonne réputation.
Vous n'avez pas à utiliser PHP pour votre site Web
Il existe de meilleures alternatives. Examinez ocsigen qui est conçu par des informaticiens qui comprennent quelque chose sur la cybersécurité, et dans haxe . Bien sûr, vous passerez des mois à l'apprendre, et si vous choisissez d'utiliser ocsigen, vous prenez un risque commercial (les personnes et les sociétés qui l'entretiennent pourraient disparaître, ce qu'on appelle facteur de bus ). Mais je connais personnellement le principal architecte et concepteur d'Ocsigen, et je peux vous assurer qu'il comprend un peu la cybersécurité (la moitié de sa thèse de doctorat porte sur ce sujet).
Je dois l'utiliser ou rien.
Non, c'est faux. Vous n'avez pas besoin d'utiliser PHP. Par exemple, lisez ce blog sur la construction de votre site Web en C++, et celui-ci sur les technologies Web dans Common LISP. Vous pouvez utiliser d'autres approches (par exemple FastCGI serveurs écrits en C++ ou en Go, votre serveur HTTP spécialisé écrit en C++ par exemple avec libonion ou avec pistache ou avec CppCMS ou Wt , en Go , en Common LISP avec SBCL). Avec Rocket.rs , vous pouvez écrire des applications Web dans Rust (et la communauté Rust) se soucie a sur la cybersécurité.) Vous pouvez programmer serveurs web dynamiques en SML . Et de nombreux serveurs web ( Apache , Lighttpd ,. ..) peut être personnalisé ou adapté à vos besoins (par exemple avec vos plugins écrits par vous pour eux) sans un seul bit de PHP chose liée).
Mon opinion biaisée est que les frameworks Web au-dessus de LISP commun ou C++ ou Go ou Rust sont généralement conçus par des informaticiens instruits qui, par profession, comprennent et se soucient de la cybersécurité. PHP = a été conçu avec un état d'esprit complètement différent: pouvoir coder rapidement des sites Web dynamiques. À l'époque PHP a été conçu (1995), la cybersécurité n'était pas une préoccupation majeure , mais être capable de créer un site Web dynamique et agréable en quelques jours était en pratique essentiel.
Mais quoi que vous utilisiez, cela a un coût. Lisez à propos de externalités . Lire J.Tirole le travail académique sur eux (il est un prix Nobel d'économie; son article sur économie simple de l'open source vaut la peine d'être lu, et le plus cité sur ce sujet). Même si c'est logiciel libre (puisque le logiciel libre est une question de liberté, pas de budget). N'oubliez pas au moins le coût de vos efforts pour l'apprendre et évaluer ses aspects de cybersécurité.
Si vous utilisez des bibliothèques open source , elles ont encore un certain coût pour vous: vous devez les apprendre, les évaluer. Ils sont généralement donnés SANS GARANTIE . Mais vous pouvez acheter un support pour ces bibliothèques.
Si vous utilisez des bibliothèques ou des composants logiciels propriétaires, vous êtes lié par leurs EULA .
La sécurité est toujours une question de compromis.
Vous pouvez ne pas boucler votre ceinture de sécurité lorsque vous conduisez, mais vous prenez alors un risque supplémentaire et vous payez pour cela (par exemple, parce que votre assurance ne vous couvrira pas en cas de problème ou parce que vous obtenez une amende). Il en va de même pour les choix logiciels.
Soyez cependant conscient de théorème de Rice . À certains égards, cela indique qu'une cybersécurité complète est impossible. Mais même vivre est une activité risquée. (Vous ou moi pourriez avoir une crise cardiaque dans quelques heures).
Votre problème n'est pas technique, mais social. Si vous utilisez un logiciel open source, vous avez la possibilité d'étudier chaque ligne de code source et d'être convaincu (ou non) que la sécurité est suffisamment bonne. Bien sûr, cela pourrait prendre des décennies (ou des siècles: une distribution Linux entière représente maintenant 20 milliards de lignes de code source). Mais vous avez le choix (et vous pouvez déléguer l'évaluation de la sécurité de chaque composant logiciel que vous utilisez).
Je pense que vous déjà suivez les conseils! Vous dites:
Je ne compte pas ceux qui sont obsolètes, abandonnés, poubelles.
Alors, quelle mesure utilisez-vous pour décider si quelque chose est "obsolète, abandonné, poubelle"? Très peu de paquets sont réellement marqués comme "abandonnés" sur des sites comme packagist.org, et "corbeille" est clairement un jugement subjectif, donc je soupçonne que votre processus réel est quelque chose comme ceci:
- Rechercher des packages d'apparence pertinente
- Voyez s'ils conviennent à votre cas d'utilisation
- Vérifier qu'ils sont de qualité raisonnable
Le fait que vous vous retrouvez souvent avec une seule option au fin de ce processus est très différent du fait qu'il n'y a qu'une seule option au début de ce processus.
Il convient également de noter que s'il existe est une bibliothèque de haute qualité pour résoudre un travail particulier, il n'y a souvent aucune incitation pour quelqu'un à en écrire un nouveau. Encore une fois, cela ne va pas à l'encontre du conseil d'utiliser des bibliothèques bien respectées, cela le renforce - s'il y a beaucoup de gens qui utilisent la même implémentation, il est plus probable que certains d'entre eux décèlent des défauts ou paient pour des audits. Il s'agit essentiellement d'une réitération de la "loi de Linus":
étant donné suffisamment de globes oculaires, tous les insectes sont peu profonds
Le seul cas où je peux voir le problème s'appliquer est où il y a non bibliothèques décentes pour un travail, car il s'agit d'un cas d'utilisation suffisamment rare pour que personne n'en ait écrit un. Dans cette situation, c'est à vous d'écrire la bibliothèque (ou de payer pour qu'elle soit écrite), et à vous de la sécuriser (ou de payer pour que quelqu'un la vérifie).