Vous ne pouvez pas contrôler des lignes de code individuelles. Vous mourrez simplement 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 des trusts. À un moment donné, vous devez faire confiance à d'autres personnes, vous devez avoir confiance que celui qui a écrit votre éditeur de texte ne cache pas automatiquement un code de cheval de Troie que l'interpréteur PHP exécutera dans un malware volant Bitcoin.

Vous doivent faire une analyse coûts-avantages pour hiérarchiser ce que vous contrôlez.

Pour la plupart, vous devez faire de votre mieux pour contrôler les auteurs du code, les pratiques de sécurité interne du projet et la manière dont le code vous parvient. En fait, la révision du code est coûteuse et difficile, il faut donc les réserver 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 au sein d'une entreprise respectable un chef de projet bien connu derrière? Le projet a-t-il mis en place des 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 qu'il doit gérer? Passe-t-il ses propres tests? Ensuite, le risque que la bibliothèque soit compromise sans que personne ne s'en aperçoive est réduit.

Prenez quelques exemples de fichiers pour une vérification plus approfondie. Voyez-vous quelque chose qui vous concerne? 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; si elles semblent bonnes, cela augmente votre confiance dans le fait que le reste de la base de code est également bien écrit. Notez que dans les bases de code très volumineuses, 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 pré-contrôle requis 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é? Celles-ci affectent la confiance que vous accordez à la bibliothèque, les facteurs de risque et la manière dont vous pouvez améliorer davantage la confiance.

Vous devez également tenir compte de l'application et de l'environnement d'exécution sur lesquels l'application s'exécutera. Est-ce pour un code de sécurité nationale? Cette gestion de code fait-elle partie d'un commerce électronique ou d'une banque traitant des numéros de carte de crédit? Ce code s'exécute-t-il en tant que superutilisateur? Ce code est-il critique pour la vie / la sécurité? Disposez-vous de contrôles compensatoires pour isoler et exécuter du code avec différents privilèges (par exemple, des conteneurs, des machines virtuelles, des autorisations utilisateur)? S'agit-il d'un code pour un projet parallèle du week-end? La façon dont vous répondez à ces questions devrait vous permettre de définir un budget sur combien vous pouvez investir dans le code de vérification, et donc comment prioriser quelles bibliothèques ont besoin d'être vérifiées, à quel niveau et lesquelles sont acceptables avec moins de confiance.

Mon arborescence de répertoires "Composer" 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 est d'essayer de contrôler le code tiers comme s'il s'agissait du vôtre. Vous ne pouvez pas et ne devriez pas essayer de faire cela.

Vous n'avez mentionné aucune des bibliothèques par leur nom, mais je vais supposer qu'une bonne partie de celle-ci est là parce que vous en utilisez une des frameworks plus larges, tels que Laravel ou Symfony. Les cadres comme celui-ci, comme avec d'autres grandes bibliothèques, 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 vérifier tout ce code vous-même, vous devez lâcher prise et faire confiance au fournisseur. 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 fichier compilé environnement comme .NET ou Java. Dans ces plates-formes, les bibliothèques sont fournies sous forme de fichiers DLL ou similaires et vous ne pourrez peut-être jamais voir le code source. Vous ne pouvez pas les contrôler et vous n'essaieriez pas. Si votre attitude envers une bibliothèque PHP est différente de cela, alors vous devez vous demander pourquoi. Ce n'est pas parce que vous pouvez lire le code que vous gagnez quoi que ce soit.

Là où tout cela tombe bien sûr, c'est si vos bibliothèques tierces incluent des bibliothèques plus petites qui sont non pris en charge ou 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 ont-elles une politique de sécurité avec laquelle vous êtes à l'aise. Pour ceux qui ne le font pas, vous pouvez envisager de trouver une alternative à ces bibliothèques. Mais cela ne signifie toujours pas que vous devriez essayer de les contrôler 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 souhaitez 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 en matière de sécurité, c'est facilement le meilleur outil d'analyse de sécurité automatisé que vous pouvez obtenir pour PHP. Exécutez-le définitivement 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 également sur vos bibliothèques tierces si vous êtes assez paranoïaque. Cela vous coûtera beaucoup plus cher, et mes points ci-dessus sont toujours valables; vous devriez vraiment faire confiance à vos fournisseurs tiers pour faire ce genre de choses par eux-mêmes.

Bienvenue dans le nouveau paradigme du codage: vous utilisez des bibliothèques en plus des bibliothèques. Vous n'êtes pas seul, mais vous devez également comprendre que chaque fois que vous introduisez du code que vous n'avez pas écrit, vous présentez un risque.

Votre question réelle est: comment puis-je gérer ce risque ?

Comprenez ce que votre logiciel est censé faire

Trop souvent, les gestionnaires de bibliothèque deviennent un moyen pratique de gifler le code en ce que "fonctionne juste", sans jamais se soucier pour comprendre à un niveau élevé ce qu'il est censé faire. Ainsi, lorsque le code de votre bibliothèque de confiance fait de mauvaises choses, vous êtes pris au dépourvu, à vous demander ce qui s'est passé. C'est là que le test unitaire peut vous aider, car il teste ce que le code est censé faire.

Connaissez vos sources

Composer (ou n'importe quel gestionnaire de paquets ) peut installer à partir de n'importe quelle source que vous spécifiez, y compris une bibliothèque cumulé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 (c'est-à-dire que quelqu'un dans le projet 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 y a un risque que vous ne pouvez jamais entièrement atténuer

En 2016, un seul développeur NodeJS a paralysé une tonne de paquets lorsqu'ils ont quitté le projet et ont demandé que leurs bibliothèques ne soient pas publiées. Ils avaient une bibliothèque simple que des centaines d'autres packages répertoriés comme dépendances. Ou peut-être que l’infrastructure n’a pas été conçue pour gérer la distribution de paquets, elle échoue donc de manière aléatoire. Internet est devenu si bon pour "faire fonctionner les choses" dans le monde du développement de logiciels distribués, que les gens ont tendance à être contrarié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 beaucoup de temps de ma part, mais j'ai pu aider l'auteur de ce paquet à 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 paquet 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 non plus ce qui est ajouté / changé à chaque mise à jour. L'un des auteurs de la bibliothèque aurait facilement pu être compromis un jour lorsque mon compositeur récupère des mises à jour, ce qui oblige mes scripts PHP CLI à envoyer soudainement mon portefeuille Bitcoin.dat à un serveur distant, à installer un RAT / cheval de Troie sur ma machine, ou même pire. En fait, cela aurait déjà pu arriver, et je ne serais pas plus sage. Je n'ai simplement aucune idée. Je n'ai logiquement aucune idée.

Cherchez Heartbleed, l'énorme faille de sécurité d'OpenSSL. Heartbleed a efficacement nerfé SSL en enregistrant d'abord les dernières centaines ou milliers de transactions (cryptées par le réseau) sous forme de texte brut, puis en laissant une installation facile et non connectée à quiconque le connaissait 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 brut. À cette époque, OpenSSL protégeait la grande majorité des sites Web auto-hébergés et un grand nombre de banques et même des services de renseignement gouvernementaux.

Recherchez ensuite Meltdown et Spectre, des bogues massifs intégrés directement dans les processeurs Intel modernes. Meltdown et Spectre neutralisent complètement l'exécution d'un processeur 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 service d'arrière-plan Windows XP (je ne suis même pas sûr que c'était un bogue - juste un stupide) service d'arrière-plan Windows XP qui ne fonctionnait même pas par défaut - il ne serait activement utilisé que par une vaste minorité d'utilisateurs Windows et uniquement connu des services informatiques. Cela a finalement conduit les FAI à émettre des pare-feu matériels intégrés à leurs modems, et a conduit Microsoft à intégrer un pare-feu logiciel intégré dans 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» a été découverte pour contenir un rootkit intégré dans la version principale de la distribution.

Comme d'autres l'ont dit: vous devez faire confiance à quelqu'un dans certains point. Les accidents et la malveillance causent des problèmes. Je suis comme vous - grand fan de The X-Files et de Uplink (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 faire un effort supplémentaire pour réinventer la roue Composer pour votre sécurité et celle de vos utilisateurs, alors soyez sérieux au sujet de cet effort supplémentaire: créez votre propre processeur, carte mère, RAM, disque dur et lecteurs optiques. Écrivez vos propres pilotes de système d'exploitation et de matériel. 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 qu'il pourrait y avoir des problèmes dans le compilateur, et ne pensez même pas au langage d'assemblage avec un assembleur que quelqu'un d'autre a écrit. Écrivez tous vos propres logiciels à partir de zéro dans les instructions de la machine, avec un éditeur hexadécimal.

Ou vous pouvez agir comme un membre de l'industrie. Abonnez-vous aux newsletters des mises à jour de Compositeur / PHP / YourLinuxDistro et participez peut-être à des newsletters indépendantes basées sur la sécurité, et souscrivez à Wired . Passez en revue 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 entrant ou sortant. Soyez proactif dans la surveillance des menaces possibles et ne soyez pas paranoïaque à propos de 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 à prendre en compte:

• Prioriser l'examen du code critique pour des raisons de sécurité. De toute évidence, cela inclurait des éléments tels que le code d'authentification et de connexion, la validation des autorisations, les intégrations du processeur de paiement . Tout ce qui demande des informations sensibles ou effectue des appels réseau.
• Survolez visuellement des éléments tels que la mise en forme des bibliothèques - vous devriez être en mesure de déterminer rapidement qu’elles ne font que du stylisme - et autres comme les fonctions utilitaires. Chaînes en majuscules, substitutions d'espaces, réorganiser les tableaux ... vous devriez être en mesure de parcourir rapidement le code et de voir qu'ils ne font rien d'inattendu.
• Même si vous ne procédez pas à l'ingénierie inverse complète du code comme si c'était le vôtre, vous devriez pouvoir jeter un coup d'œil à la source et déterminer si elle était censée être favorable au reverse-engineering . 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 implémentations ne doivent pas être trop longues ou trop complexes ou contenir des fonctionnalités inutiles. Un code très agréable à regarder n'est certainement pas le vecteur d'attaque préféré des pirates malveillants.
• Confirmez que le code dispose d'une base d'utilisateurs établie et mature fort>. Vous souhaitez vous tourner vers des projets que les entreprises rentables et bien connues sont connues pour utiliser.
• Confirmez les identités réelles des contributeurs principaux . Pour les projets à grande échelle, le développeur principal se fera un plaisir de s'attribuer le mérite de son travail. Vous devriez pouvoir trouver des articles de blog, des comptes de médias sociaux et probablement un CV ou une page marketing pour le travail de conseil. Contactez-moi! etc.
• Confirmez que le code open source est activement maintenu avec les corrections de bogues récentes. Regardez les rapports de bogues exceptionnels - 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 illusoire.
• Évitez les sites "gratuits" avec des publicités excessives. Évitez les projets qui n'ont pas de site de démonstration disponible, ou où la démonstration est "moche", mal entretenue ou souvent hors ligne. Évitez les projets qui sont trop médiatisés, ou les mots à la mode excessifs, font des déclarations non testées de performances supérieures. Évitez de télécharger à partir de blogs anonymes. Etc.
• Penser malicieusement . Si vous vouliez casser votre site, qu'essaieriez-vous? Si vous vouliez insérer du code non sécurisé dans une bibliothèque largement utilisée, comment le feriez-vous? (N'essayez pas vraiment cela, évidemment.)
• Fork projets open-source, ou téléchargez des 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, ayez juste une idée de ce que fait chaque bibliothèque, et pourquoi vous pensez qu'elle le fait. 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!

Composer peut travailler avec un fichier composer.lock et, par défaut, télécharger des packages via https://packagist.org/ (notez le HTTP S .) Vous disposez donc d'un énorme référentiel de paquets 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é une fois. Cela seul vous aide beaucoup.

Si vous restez sur le côté conservateur des mises à jour de dépendances, vous pouvez également vous attendre à ce que les versions du package aient été utilisées en production.

En fin de compte, cependant , vous devrez faire confiance à quelqu'un. Vous pouvez soit vous faire confiance pour écrire du code sans exploit, soit vous pouvez, comme d'autres, faire confiance aux projets communautaires utilisés par des milliers et vus par encore plus d'utilisateurs.

En fin de compte, je ne pense pas que vous Avoir le choix. Si d'autres «volent à l'aveuglette», c'est-à-dire sans les audits de sécurité que vous souhaitez faire, et acceptent «vos» clients avec des prix plus bas et des versions de fonctionnalités plus rapides, personne ne bénéficiera de toute façon de votre application auto-écrite sécurisée.