Comment vais-je pouvoir "vérifier" plus de 120 000 lignes de Composer PHP code non écrit par moi?)
Je dépends de PHP CLI pour toutes sortes de "logique métier" personnelle et (je l'espère bientôt) professionnelle/critique. (Cela pourrait être n'importe quel autre langage et le même problème se poserait toujours) ; Je déclare simplement ce que j'utilise personnellement pour le contexte.)
Dans la mesure du possible, je code toujours tout par moi-même. Ce n'est qu'en cas d'absolue nécessité que j'ai recours à contrecœur à l'utilisation d'une bibliothèque tierce. Pour certaines choses, cela est simplement nécessaire. Par exemple, l'analyse des e-mails et d'autres choses très compliquées comme ça.
Pour gérer ces bibliothèques tierces, j'utilise PHP Composer . C'est un gestionnaire de bibliothèque pour PHP. Il est capable de télécharger des bibliothèques et leurs dépendances, et de les mettre à jour avec des commandes similaires aux autres "gestionnaires de paquets". Dans un sens pratique, c'est beaucoup plus agréable que de garder une trace manuelle de cela et de télécharger manuellement les fichiers Zip et de les décompresser et de traiter toutes sortes de problèmes. Cela évite au moins beaucoup de maux de tête pratiques.
Cependant, le problème de sécurité le plus fondamental persiste: je n'ai aucune idée de ce que contient ce code "installé", ni puis-je savoir ce qui est ajouté/changé à chaque mise à jour. L'un des auteurs des bibliothèques aurait pu facilement être compromis un jour lorsque mon Composer récupère les mises à jour, ce qui fait que mes scripts PHP CLI envoient soudainement mon portefeuille Bitcoin.dat sur un serveur distant, installez un RAT/cheval de Troie sur ma machine, ou pire encore. En fait, cela aurait déjà pu se produire, et je ne serais pas plus sage. Je n'en ai simplement aucune idée. Je ne peux logiquement pas avoir d'idée.
Ma propre base de code compte environ 15 000 lignes au total. Il me faut plus d'un an pour parcourir minutieusement cette base de code. Et c'est du code que [~ # ~] j'ai [~ # ~] que j'ai écrit et que je connais intimement ...
Mon arborescence de répertoires "Compositeur" se trouve actuellement à plus de 120 000 lignes de code. Et c'est pour le minimal nombre de crucial PHP bibliothèques dont j'ai besoin. J'utilise très peu, mais elles ont divers dépendances et ont tendance à être très gonflées/gonflées par rapport à mon propre code.
Comment suis-je censé "contrôler" tout cela?! Cela n'arrivera tout simplement pas. Je "zone" très peu de temps après avoir même essayé. Je ne sais même pas comment je vais passer par un autre "cycle vétérinaire" de le mien code - encore moins ce 10x plus grand, codé par d'autres personnes.
Quand les gens disent que c'est un "must" pour "vérifier le code tiers", que signifient-ils exactement? Je conviens également que c'est un "must", mais il y a ensuite la réalité embêtante. Je n'aurai tout simplement jamais le temps et l'énergie pour le faire. De plus, je n'ai évidemment pas l'argent pour payer quelqu'un d'autre pour le faire.
J'ai passé d'innombrables heures à essayer d'en apprendre plus sur Docker et à voir s'il y avait un moyen de "résumer" ces bibliothèques tierces non fiables, mais c'est une bataille perdue. J'ai trouvé qu'il était tout à fait impossible de faire avancer les choses, ou j'ai répondu à l'une de mes nombreuses questions à ce sujet. Je ne pense même pas que ce soit possible de la façon dont je l'imagine.
Vous ne pouvez pas contrôler des lignes de code individuelles. Vous mourrez juste en essayant de faire ça.
À un moment donné, vous devez faire confiance à quelqu'un d'autre. En 1984, Ken Thompson, l'un des co-inventeurs d'une grande partie d'Unix, a écrit un court article sur les limites de trusts . À un moment donné, vous devez faire confiance à d'autres personnes, vous devez vous assurer que celui qui a écrit votre éditeur de texte ne cache pas automatiquement du code de cheval de Troie que l'interpréteur PHP exécutera dans certains logiciels malveillants de vol de Bitcoin .
Vous devez faire une analyse coûts-avantages pour prioriser ce que vous examinez.
Pour la plupart, vous devez faire de votre mieux pour vérifier les auteurs du code, les pratiques de sécurité interne du projet et la façon dont le code vous parvient. En fait, la révision du code est coûteuse et difficile, donc ils doivent être réservés aux parties que vous considérez les plus importantes pour votre projet.
La bibliothèque est-elle une bibliothèque populaire utilisée par de nombreuses personnes avec une entreprise respectable ou un projet bien connu derrière elle? Le projet dispose-t-il de processus de gestion de projet appropriés? La bibliothèque a-t-elle un bon historique des problèmes de sécurité et comment les a-t-elle traités? At-il des tests pour couvrir tous les comportements dont il a besoin pour gérer? Réussit-il ses propres tests? Le risque que la bibliothèque soit compromise sans que personne ne s'en aperçoive est alors réduit.
Prenez quelques exemples de fichiers pour une vérification plus approfondie. Voyez-vous quoi que ce soit à ce sujet? Si les quelques fichiers que vous avez pris ont des problèmes majeurs, vous pouvez probablement en déduire que le reste de la base de code a des problèmes similaires; s'ils semblent bons, cela vous donne confiance que le reste de la base de code est également bien écrit. Notez que dans de très grandes bases de code, il y aura différentes zones du code avec différents niveaux de qualité de code.
Votre référentiel de gestionnaire de packages vérifie-t-il la signature du package? Existe-t-il un système de contrôle préalable pour enregistrer un package dans le référentiel ou s'agit-il d'un référentiel d'enregistrement ouvert? Recevez-vous la bibliothèque sous forme de code source ou sous forme de binaire précompilé? Ceux-ci affectent dans quelle mesure vous pouvez faire confiance à la bibliothèque, les facteurs de risque et comment vous pouvez encore améliorer la confiance.
Vous devez également prendre en compte l'application et l'environnement d'exécution sur lesquels l'application s'exécutera. Est-ce pour un code de sécurité nationale? Ce code fait-il partie d'un commerce électronique ou d'une banque qui gère les numéros de carte de crédit? Ce code fonctionne-t-il en tant que super-utilisateur? Ce code est-il critique pour la durée de vie/la sécurité? Avez-vous des contrôles compensatoires pour isoler et exécuter du code avec différents privilèges (par exemple, conteneurs, machines virtuelles, autorisations utilisateur)? Ce code est-il pour un projet parallèle le week-end? La façon dont vous répondez à ces questions devrait vous permettre de définir un budget sur le montant que vous pouvez investir dans le code de vérification, et donc comment hiérarchiser les bibliothèques qui ont besoin de vérification, à quel niveau, et celles qui conviennent bien avec une confiance moindre.
Mon arborescence de répertoires "Compositeur" compte actuellement plus de 120 000 lignes de code. Et c'est pour le nombre minimal de bibliothèques PHP cruciales dont j'ai besoin.
Votre erreur consiste à essayer de vérifier le code tiers comme s'il était le vôtre. Vous ne pouvez et ne devez pas essayer de le faire.
Vous n'avez mentionné aucune bibliothèque par son nom, mais je vais supposer qu'il y en a une bonne partie car vous utilisez l'un des cadres les plus grands, comme Laravel ou - Symfony . Des cadres comme celui-ci, comme avec d'autres bibliothèques importantes, ont leurs propres équipes de sécurité; les problèmes sont corrigés rapidement et l'installation des mises à jour est triviale (tant que vous êtes sur une version prise en charge).
Plutôt que d'essayer de contrôler vous-même tout ce code, vous devez laisser aller et croire que le fournisseur a fait - et continue de faire - cette vérification pour vous. C'est, après tout, pourquoi l'une des raisons pour lesquelles vous utilisez du code tiers.
De manière réaliste, vous devriez traiter les bibliothèques PHP tierces exactement de la même manière que vous traiteriez les bibliothèques tierces dans un environnement compilé comme . NET ou Java. Sur ces plates-formes, les bibliothèques se présentent sous la forme de fichiers DLL ou similaires et vous ne pourrez peut-être jamais voir le code source. Vous ne pouvez pas les examiner et vous n'essaieriez pas. Si votre attitude envers une bibliothèque PHP est différente de celle-ci, alors vous devez vous demander pourquoi. Ce n'est pas parce que vous pouvez lire le code que vous gagnez à le faire.
Bien sûr, tout cela tombe si vos bibliothèques tierces incluent des bibliothèques plus petites qui ne sont pas prises en charge ou qui n'ont pas de politique de sécurité. Voici donc la question que vous devez poser à toutes les bibliothèques que vous utilisez: sont-elles entièrement prises en charge et disposent-elles d'une politique de sécurité avec laquelle vous êtes à l'aise? Pour ceux qui ne le font pas, vous voudrez peut-être envisager de trouver une alternative à ces bibliothèques. Mais cela ne signifie toujours pas que vous devez essayer de les vérifier vous-même, à moins que vous n'ayez réellement l'intention de prendre en charge leur soutien.
Une chose que j'ajouterai cependant: si vous voulez faire un audit de sécurité sur votre code PHP, je vous recommande fortement d'utiliser le scanner RIPS . Ce n'est pas bon marché, mais si vous avez de fortes exigences de sécurité, c'est facilement le meilleur outil d'analyse de sécurité automatisé que vous pouvez obtenir pour PHP. Exécutez-le certainement sur votre propre code; vous serez probablement surpris du nombre de problèmes qu'il détecte. Vous pouvez bien sûr l'exécuter sur vos bibliothèques tierces également si vous êtes assez paranoïaque. Cela vous coûtera cependant beaucoup plus, et mes points ci-dessus sont toujours valables; vous devriez vraiment faire confiance à vos fournisseurs tiers pour faire ce genre de chose par eux-mêmes.
Bienvenue dans le nouveau paradigme du codage: vous utilisez des bibliothèques au-dessus des bibliothèques. Vous n'êtes guère seul, mais vous devez également comprendre que chaque fois que vous apportez du code que vous n'avez pas écrit, vous apportez des risques.
Votre véritable question est comment puis-je gérer ce risque?
Comprendre ce que votre logiciel est censé faire
Trop souvent, les gestionnaires de bibliothèque deviennent un moyen pratique de gifler du code dans la mesure où "ça marche", sans jamais prendre la peine de comprendre à un niveau élevé ce qu'il est censé faire. Ainsi, lorsque votre code de bibliothèque de confiance fait de mauvaises choses , vous êtes pris à plat, vous vous demandez ce qui s'est passé. C'est là que tests unitaires peut aider, car il teste ce que le code est censé faire.
Connaissez vos sources
Composer (ou n'importe quel gestionnaire de packages) peut installer à partir de n'importe quelle source que vous spécifiez, y compris une bibliothèque remontée hier par une source complètement inconnue. J'ai volontairement installé des packages de fournisseurs qui ont des SDK, car le fournisseur est une source hautement fiable. J'ai également utilisé des packages provenant de sources qui effectuent d'autres travaux de confiance (par exemple, quelqu'un dans le PHP a un dépôt de bibliothèque). Faire confiance aveuglément à n'importe quelle source peut vous causer des ennuis.
Acceptez qu'il existe un risque que vous ne pouvez jamais atténuer complètement
En 2016, un seul développeur NodeJS a paralysé une tonne de packages quand ils ont quitté le projet et ont exigé que leurs bibliothèques ne soient pas publiées. Ils avaient une bibliothèque simple que des centaines d'autres packages listaient comme une dépendance. Ou peut-être l'infrastructure n'a pas été construite pour gérer la distribution des paquets donc elle échoue de façon aléatoire. Internet est devenu si bon à "faire fonctionner les choses" dans le monde du développement de logiciels distribués, que les gens ont tendance à être bouleversés ou confus quand il cesse de fonctionner.
Lorsque PHP 7.0 est sorti, j'ai dû faire une tonne de travail pour créer un progiciel tiers open source que nous utilisons dans l'environnement 7.0. Cela a pris un temps considérable de ma part, mais j'ai pu aider l'auteur de ce package à résoudre certains problèmes et à le rendre utilisable dans l'environnement 7.0. L'alternative était de le remplacer ... ce qui aurait pris encore plus de temps. C'est un risque que nous acceptons car ce package est très utile.
Cependant, le problème de sécurité le plus fondamental persiste: je n'ai aucune idée de ce que contient ce code "installé", et je ne sais pas ce qui est ajouté/changé à chaque mise à jour. L'un des auteurs des bibliothèques aurait pu facilement être compromis un jour lorsque mon Composer récupère les mises à jour, ce qui fait que mes scripts PHP CLI envoient soudainement mon portefeuille Bitcoin.dat sur un serveur distant, installez un RAT/cheval de Troie sur ma machine, ou pire encore. En fait, cela aurait déjà pu se produire, et je ne serais pas plus sage. Je n'en ai simplement aucune idée. Je ne peux logiquement pas avoir d'idée.
Look up Heartbleed , le trou de sécurité massif dans OpenSSL. Heartbleed a efficacement effacé SSL en enregistrant d'abord les plusieurs centaines ou milliers de transactions (cryptées par le réseau) sous forme de texte en clair, puis en laissant une installation facile et non journalisée à toute personne qui en avait connaissance pour se connecter à distance et récupérer toutes les transactions en mémoire cache que les utilisateurs pensaient ont été cryptés en toute sécurité, en texte clair. À ce moment-là, OpenSSL protégeait la grande majorité des sites Web auto-hébergés et un grand nombre de banques et même de services de renseignement gouvernementaux.
Recherchez ensuite Meltdown et Spectre , des bugs massifs intégrés directement dans les processeurs Intel modernes. Meltdown et Spectre neutralisent complètement l'exécution d'un CPU en mode protégé et, étant indépendants du système d'exploitation, sont exploitables sur tous les systèmes d'exploitation.
Il y a des années et des années, un logiciel malveillant appelé MSBlaster exploitait un (je ne suis même pas sûr qu'il s'agissait d'un bogue - juste un stupide exceptionnel) Windows XP service d'arrière-plan qui ne fonctionnait même pas par défaut - il ne serait utilisé activement que par une grande minorité d'utilisateurs de Windows, puis uniquement connu des services informatiques. Cela a finalement conduit les FAI à émettre des pare-feu matériels intégrés à leurs périphériques de modem, et a poussé Microsoft à intégrer un pare-feu logiciel intégré à leurs systèmes d'exploitation. À peu près à la même époque, une distribution de la plate-forme Linux prétendument "à l'épreuve des virus" contenait un rootkit intégré dans la version de distribution principale.
Comme d'autres l'ont dit: vous devez faire confiance à quelqu'un à un moment donné. Les accidents et la malveillance causent des problèmes. Je suis comme toi - grand fan de Les X-Files et - plink (NE FAITES CONFIANCE À PERSONNE!) - mais la réalité est que votre moteur de cryptographie SSL ou vos périphériques matériels physiques sont tout aussi susceptibles de présenter des failles de sécurité et celles-ci sont beaucoup plus susceptibles de représenter des défaillances critiques lorsqu'elles se présentent.
Si vous voulez vraiment aller plus loin pour réinventer la roue Composer pour votre sécurité et celle de vos utilisateurs, alors soyez sérieux si vous voulez aller plus loin: créez votre propre CPU, carte mère, RAM, Disque dur et lecteurs optiques. Écrivez votre propre système d'exploitation et vos pilotes matériels. Créez également vos propres compilateurs. Et oubliez PHP car il pourrait y avoir des problèmes dans l'interpréteur - en fait, oubliez aussi C et C++ parce que il pourrait y avoir des problèmes dans le compilateur, et ne pensez même pas au langage d'assemblage avec un assembleur écrit par quelqu'un d'autre. Écrivez tous vos propres logiciels à partir de zéro dans les instructions de la machine, avec un éditeur hexadécimal.
Ou vous pourriez agir comme un membre de l'industrie. Abonnez-vous aux newsletters des mises à jour de Composer/PHP/YourLinuxDistro et peut-être aussi obtenir des newsletters indépendantes basées sur la sécurité, et obtenez un abonnement à Wired. Consultez vos journaux système. Testez régulièrement votre réseau avec un PCAP pour vous assurer qu'il n'y a pas de flux réseau non autorisés entrants ou sortants. Soyez proactif dans la surveillance des menaces possibles et ne soyez pas paranoïaque face à des choses qui ne se sont pas encore produites.
En tant que développeur de niveau intermédiaire à avancé, j'ai considéré le même problème. Quelques points à considérer:
- Prioriser revoir le code qui est critique pour des raisons de sécurité. Évidemment, cela inclurait des éléments comme l'authentification et le code de connexion, la validation des autorisations, les intégrations du processeur de paiement . Tout ce qui demande des informations sensibles ou passe des appels réseau.
- Visuellement écrémé des choses comme les bibliothèques de style - vous devriez être en mesure de déterminer rapidement qu'elles ne font que du style - et des choses comme les fonctions utilitaires. En majuscules, en remplaçant les espaces blancs, en réorganisant les tableaux ... vous devriez pouvoir parcourir rapidement le code et voir qu'ils ne font rien d'inattendu.
- Même si vous n'effectuez pas de reverse engineering complet comme si c'était le vôtre, vous devriez pouvoir jeter un coup d'œil à la source et déterminer s'il était destiné être favorable à la rétro-ingénierie . Le code doit être documenté avec des commentaires utiles, les noms de variables et de méthodes doivent être pertinents et utiles, les fonctions et les implémentations ne doivent pas être trop longues ou trop complexes ou contenir des fonctionnalités inutiles. Code très agréable à l'œil n'est certainement pas le vecteur d'attaque préféré des pirates malveillants.
- Confirmez que le code a une base d'utilisateurs établie et mature. Vous voulez vous orienter vers des projets que des entreprises rentables et connues sont connues pour utiliser.
- Confirmez identités réelles des principaux contributeurs. Pour les projets à grande échelle, le développeur principal se fera un plaisir de prendre le crédit de son travail. Vous devriez être en mesure de trouver des articles de blog, des comptes de médias sociaux et probablement un curriculum vitae ou une page de marketing pour des travaux de consultation. Contactez-moi! etc.
- Confirmez que le code open-source est activement maintenu avec des corrections de bugs récentes. Regardez les rapports de bogues en suspens - il y en a forcément quelques-uns - et ne vous fiez pas aux affirmations selon lesquelles un outil ou une bibliothèque en particulier est exempt de bogues. C'est une affirmation délirante.
- Évitez les sites "gratuits" avec des publicités excessives. Évitez les projets qui ne disposent pas d'un site de démonstration, ou où la démonstration est "moche", mal entretenue ou fréquemment hors ligne. Évitez les projets sur-médiatisés ou les mots à la mode excessifs, faites des réclamations non testées de performances supérieures. Évitez de télécharger à partir de blogs anonymes. Etc.
- Pensez avec malveillance. Si vous vouliez casser votre site, qu'essaieriez-vous? Si vous vouliez introduire du code dangereux dans une bibliothèque largement utilisée, comment le feriez-vous? (N'essayez pas vraiment, évidemment.)
- Fork projets open-source, ou téléchargement de sauvegardes. Ne croyez jamais que le dépôt officiel du projet open source que vous aimez restera en ligne indéfiniment.
Donc, au lieu d'essayer de lire et de comprendre chaque ligne de code individuellement, faites-vous une idée de ce que chaque bibliothèque fait, et pourquoi vous croyez que cela fait cela. Je pense vraiment que, si votre travail est rentable, il n'y a pas de limite supérieure à la taille d'un projet; vous pouvez "contrôler" plus de 1 200 000 lignes de code ou plus de 120 000 000 lignes de code!
Le compositeur peut travailler avec un composer.lock fichier et, par défaut, télécharge les packages via https://packagist.org/ (notez le HTTP [~ # ~] s [~ # ~] .) Vous disposez donc d'un énorme référentiel de packages et d'un téléchargement sécurisé avec la somme de contrôle SHA1 qui l'accompagne pour vous assurer de télécharger exactement ce qui a été spécifié. Cela seul vous aide beaucoup.
Si vous restez du côté conservateur des mises à jour des dépendances, vous pouvez également vous attendre à ce que les versions du package aient vu l'utilisation de la production.
En fin de compte, vous devrez faire confiance à quelqu'un. Vous pouvez soit vous faire confiance pour écrire du code sans exploit, soit, comme d'autres, faire confiance à des projets communautaires utilisés par des milliers de personnes et vus par encore plus d'utilisateurs.
En fin de compte, je ne pense pas que vous ayez le choix. Si d'autres "volent à l'aveuglette", c'est-à-dire sans les audits de sécurité que vous voulez faire, et emmènent "vos" clients avec des prix plus bas et des versions de fonctionnalités plus rapides, personne ne bénéficiera jamais de votre application auto-écrite sécurisée de toute façon.