Ce n'est pas tant que PHP lui-même a des problèmes de sécurité (en supposant que les mises à jour de sécurité sont nécessaires), car il existe de nombreux logiciels PHP populaires avec des problèmes de sécurité rampants. Vous pourriez reprocher à PHP d'être un langage qui vous donne assez de corde pour vous étouffer, mais le vrai problème est à quel point le code PHP est vulnérable. Il n'est pas nécessaire de chercher plus loin que la balise PHP Stack Overflow pour trouver des débutants en PHP écrivant du code horriblement vulnérable basé sur une atrocité d'un ancien didacticiel.

De plus, un nombre important de PHP populaires un logiciel connu pour ses failles de sécurité rampantes est basé sur un code et des pratiques de codage très anciens . Beaucoup de ces vieilles pratiques sont considérées comme de mauvaises pratiques en raison de problèmes de sécurité inhérents.

Cela, pour moi, ressemble à dire à quelqu'un de ne jamais conduire pour éviter un accident de voiture.

À peu près oui. Un meilleur conseil pourrait être du type "ne conduisez pas une vieille voiture sans airbags".

Mon instinct est que l'hôte essaie de rejeter la responsabilité sur le client pour les failles de sécurité dans leur propre système.

Pas nécessairement. Si un utilisateur utilise le même mot de passe pour le site WordPress et cPanel, compromettre le mot de passe WordPress compromet également cPanel. Ce serait la faute de l'utilisateur. Les pirates informatiques ont rarement besoin d'aller aussi loin, et utilisent simplement un shell PHP.

J'ai dit à mon client que pour traiter le formulaire de contact, ils auront besoin d'une forme de script dynamique. (Faux?)

Pas nécessairement vrai. Vous pouvez utiliser un service tiers pour gérer l'envoi du courrier. Ensuite, le service gère le script de serveur dynamique et prend en charge les implications de sécurité. De nombreux services de ce type sont disponibles avec différents ensembles de fonctionnalités, et ils sont populaires pour alimenter les formulaires de contact sur les sites générés statiquement.

Dans quelle mesure l'affirmation selon laquelle l'utilisation de n'importe quel script PHP, aussi simple soit-elle, est-elle un problème de sécurité inhérent?

Certains, mais pas beaucoup. PHP implique du code actif, à la fois dans PHP et dans le logiciel serveur qui l'exécute. S'il y avait une faille de sécurité dans ce processus qui ne dépendait pas d'un code PHP spécifique, elle pourrait être exploitée. Bien que ce risque soit minime, c'est un risque qu'un serveur sans un tel support n'a pas.

«Bien» n'est peut-être pas le mot juste, mais «sage», «prudent» et «consciencieux» viennent à l'esprit. PHP a, depuis sa création, adhéré à une philosophie qui dévalorise la correction dans les logiciels. Il y a un grand nombre de situations qu'un programme peut rencontrer où d'autres langages (par exemple Python) abandonneraient et lanceraient une erreur pour vous dire que votre programme est faux, mais PHP choisit à la place de faire quelque chose d'absolu et de continuer comme si les choses étaient juste très bien.

Gardez à l'esprit que l'exactitude est très importante pour la sécurité. Un langage enclin à ignorer silencieusement les erreurs à gauche et à droite aura plus que sa juste part de programmes avec des problèmes de sécurité. Par exemple, vous pouvez avoir un morceau de code qui, selon vos programmeurs, protège contre une certaine attaque, mais qui est en fait ignoré car l'interpréteur ignore une erreur.

De plus:

• PHP est conçu pour plaire au plus petit dénominateur des programmeurs avec le moins de motivation pour devenir bon dans leur métier. Et donc le plus susceptible d'écrire des logiciels non sécurisés.
• L'équipe PHP a une histoire de tentatives profondément imparfaites pour résoudre les problèmes de sécurité courants. Regardez par exemple la protection contre les injections SQL, qui trahit des tentatives répétées erronées de résolution du problème: real_escape_string (parce que la escape_string d'origine était cassée, mais ils ne l'ont supprimée que plus tard ) contre ajoute des barres obliques contre mysql_escape_string / pg_escape_string et ainsi de suite. Alors que presque tous les autres langages ont simplement utilisé des instructions préparées et des paramètres de requête et ont obtenu une conception extensible à toutes les bases de données dès le premier essai. peut écrire des logiciels sécurisés en PHP, si vous l'essayez, vous nagez beaucoup à contre-courant.

Les problèmes de sécurité de PHP peuvent généralement être réduits à deux catégories

Systèmes non corrigés

À l'heure actuelle, les statistiques Wordpress affichent plus de la moitié de tous les utilisateurs exécutent PHP sur des versions de PHP qui sont passées en Fin de vie (PHP 5.2 - 5.4). En deux semaines, PHP 5.5 passe à EOL, puis il passe à environ 80% de toutes les installations. Maintenant, pour être honnête, certaines installations Linux Enterprise / LTS rétroporteront les correctifs de sécurité, mais la grande majorité d'entre eux n'utilisent pas de correctifs rétroportés (ou certains ne corrigent pas leurs systèmes). Pire encore, beaucoup de gens refusent de mettre à jour PHP lui-même. Soit ils ne peuvent pas / ne veulent pas mettre à jour leur code, soit ils pensent que les anciens logiciels sont plus stables.

Wordpress (application PHP n ° 1 utilisée dans le monde) a fait un effort concerté pour s'assurer que les utilisateurs restent informés date sur le logiciel lui-même (et ils ont fait de grands progrès), mais malgré cela, seuls 40% utilisent la dernière version de Wordpress. Cela signifie qu'environ 60% peuvent avoir une vulnérabilité de sécurité non corrigée. Et ce n'est que le programme de base. Wordpress a un énorme écosystème de plugins, et beaucoup d'entre eux ont leurs propres vulnérabilités de sécurité.

Ensuite, il y a d'autres problèmes, comme beaucoup de code plus ancien utilisant le défunt mcrypt bibliothèque. Et ce n'est qu'un plugin PHP que vous pouvez compiler.

Maintenant extrapolez ceci aux serveurs qui ne fonctionnent pas et rapportez les statistiques à WP. Cela ne brosse pas un joli tableau. L'été dernier, j'ai trouvé un site Web exécutant une page de commerce électronique qui était toujours sur Apache 1.3.3 et PHP 4.1.2. Il était si ancien que SSLv2 était activé ...

Mauvaises pratiques

Si vous traitez assez longtemps des questions SO PHP, vous verrez beaucoup de gens pratiquer du mauvais code. Certains des problèmes que j'ai rencontrés au fil des ans

• Injection SQL
• Penser MD5 est un bon moyen de protéger les mots de passe
• Utiliser des API obsolètes int leur code (c'est-à-dire ext / mysql , l'ancien connecteur MySQL)
• Faire confiance à l'entrée de l'utilisateur pour exécuter le code (c'est-à-dire en utilisant eval avec les données fournies par l'utilisateur)
• Ne pas désactiver les risques de sécurité dans le code PHP (c'est-à-dire la fonction exec)

Pour les non formés, cela ressemble à un problème PHP, quand c'est le codeurs et leurs écosystèmes qui produisent les problèmes. Peut-être étaient-ils pressés. Peut-être ont-ils embauché un type qui fait ça pendant son temps libre et "a fait que ça marche".

Est-ce que ça peut être sécurisé?

OUI! Mais cette sécurité nécessite des efforts. Gardez votre installation PHP à jour. Heck, gardez tout votre serveur à jour. L'hôte ne fera pas la sécurité et les correctifs? Trouvez un autre hôte. (Je suis étonné de voir les gens qui rechignent à cela). Créez votre propre serveur (les machines virtuelles sont bon marché). Mais surtout, faites attention. Apprenez tout ce que vous pouvez sur la sécurité. Ne laissez pas simplement votre site Web et votre serveur aller en mer.

Quelqu'un qui vous dit que PHP n'est pas sûr est juste paresseux.

PHP n'est ni moins, ni plus sûr, ni plus sûr que tout autre langage (Java, Rails, etc.). Tout est question de codage. Des freins et contrepoids sont-ils en place pour détourner, défendre, prévenir et / ou atténuer une attaque. Citant:

WhiteHat Security a effectué des évaluations de vulnérabilité de plus de 30 000 sites Web en utilisant .NET, Java, ASP, PHP, Cold Fusion et Perl. Les langages les plus utilisés étaient .NET (28,1% des applications Web), Java (24,9%) et ASP (15,9%).

...

Le langage de programmation .Net avait en moyenne 11,36 vulnérabilités par emplacement, Java 11,32 et ASP 10,98. Le langage le plus sécurisé, ColdFusion, avait six vulnérabilités par emplacement. Perl avait sept vulnérabilités par slot et PHP en avait 10.

...

Java représentait 28% des vulnérabilités trouvées et ASP 15%. «Encore une fois, le nombre d'applications rédigées dans la langue ainsi que la complexité des sites Web doivent être considérés comme un facteur contributif», indique le rapport. PHP représentait également 15% des vulnérabilités découvertes. ColdFusion ne représentait que 4% des vulnérabilités et Perl 2%. ( source)

Cela ne dit rien sur la façon dont les sites ont été développés en termes de bonnes pratiques de codage. Par exemple, si vous prenez des programmeurs non qualifiés (faute de meilleurs termes) dans chaque langue, ces nombres pourraient être inversés et perl pourrait avoir le plus de vulnérabilités, avec .Net en ayant le moins. Tout se résume à ce que le code lui-même est censé faire. Le code a-t-il été programmé pour remplir sa seule fonction avec une falsification / abus testé avant d'être mis en développement?

Il existe de nombreuses feuilles de triche de sécurité, guides de bonnes pratiques et d'autres articles qui couvrent les problèmes de sécurité, mais cela devient une situation où le client est fatigué sur la base des conseils de son fournisseur. Cela peut être un obstacle car cela devient une sorte de "dit-il" dit-elle une sorte de lutte pour convaincre votre client de vous permettre de créer le site en PHP. Une méthode que je pourrais utiliser si je voulais toujours utiliser PHP serait de créer un site de démonstration, puis d'utiliser un scanner d'évaluation de vulnérabilité (Acunetix, AppScan, Burpsuite) pour vérifier les failles. Si aucun n'est trouvé, je présenterais le rapport détaillant la posture de sécurité de ce que vous avez construit à la fois au client et créerais de telle manière (PDF, etc.) qu'il soit présentable au fournisseur.

L'un des problèmes fondamentaux de PHP est en réalité un problème fondamental avec le modèle CGI des choses (sur lequel PHP est basé, malgré les pièges de mod_php ) - à savoir que les données des utilisateurs sont entremêlées avec des scripts, et cela devient très facile pour par exemple l'utilisateur télécharge pour devenir un script exécutable. Ce n'est pas nécessairement un problème avec PHP lui-même, mais avoir PHP disponible sur un système en fait une très grande surface d'attaque; un certain nombre de problèmes de sécurité des plugins WordPress proviennent de cet aspect, par exemple.

Les déploiements traditionnels basés sur CGI ont historiquement atténué ce problème en permettant uniquement aux scripts CGI de s'exécuter à partir d'un répertoire de confiance (tel que / cgi-bin / ) mais de nombreux fournisseurs d'hébergement partagé ont finalement assoupli cette restriction pour des raisons de "commodité", et cette même commodité est omniprésente dans PHP.

De nombreuses applications modernes basées sur PHP utilisent souvent .htaccess en tant que mécanisme de routage de requêtes rapide et efficace qui aide à atténuer ces problèmes, mais c'est loin d'être universel et n'est toujours pas une solution facile.

À mon avis, le plus gros problème avec PHP est simplement qu'il est si facile que du code PHP arbitraire soit rendu disponible pour s'exécuter sur n'importe quel serveur sur lequel il est configuré, et donc si le code écrit en PHP n'est pas nécessairement plus ou moins sécurisé que le code écrit dans d'autres langues (bien que sa bibliothèque standard ne fasse pas exactement de faveur quand il s'agit d'écrire cure code), le mécanisme par lequel les scripts PHP s'exécutent constitue un défi de sécurité massif, car PHP est même disponible sur un serveur.

Je suis d'accord avec votre évaluation selon laquelle l'utilisation de PHP ne nécessite pas de risque de sécurité. Certains fournisseurs hésitent à utiliser PHP pour la même raison que WordPress est considéré comme un risque de sécurité. C'est à la mode. Plus quelque chose est répandu, plus l'énergie est investie dans le développement d'exploits.

Cela dit, je n'éviterais pas PHP s'il est mis en œuvre correctement, reçoit des correctifs en temps opportun et dispose d'un certain niveau de surveillance pour détecter les activités malveillantes . Conclusion: les risques de sécurité sont indépendants des risques de sécurité de la plate-forme. Changer les langages de script n'atténue pas les risques de sécurité associés à un code mal écrit / développé / implémenté.

Si tout ce que vous voulez est d'inclure un en-tête / pied de page standard, PHP pourrait être exagéré - de simples inclusions côté serveur pourraient le faire.

PHP n'est pas intrinsèquement dangereux, comme l'ont soutenu les réponses précédentes. Mais si vous n'avez pas besoin d'un langage de script complet sur le serveur, la meilleure pratique de sécurité consiste à ne pas en installer un. Si, comme vous le dites, PHP va de toute façon être installé sur le serveur, alors le risque supplémentaire créé en l'utilisant est d'environ zéro tant que vous ne faites rien de stupide. Et inclure un modèle n'est pas stupide à moins que vous n'analysiez le nom du fichier à partir d'un paramètre d'URL.

Le formulaire de contact aura besoin d'une sorte d'API et de base de données derrière lui pour gérer la requête POST lorsque quelqu'un la soumet et c'est la qualité de l'écriture de cette partie va faire ou défaire les choses - quel que soit le langage que vous utilisez, s'il s'agit d'une base de données SQL, l'injection SQL vaut la peine d'être recherchée; si l'entrée de l'utilisateur est de quelque manière renvoyée à eux ou au client dans une page Web, alors l'injection de script (java) doit être prise en compte et tout doit être correctement échappé au HTML. Par rapport au formulaire de contact, l'utilisation d'un include est aussi sûre que possible.

Si vous ne vouliez qu'un ensemble de pages Web, pas une application Web interactive, le nec plus ultra en matière de sécurité est d'utiliser un générateur de site statique - le serveur n'a qu'à servir des fichiers, ce qui donne une surface d'attaque beaucoup plus petite.

So:

Dans quelle mesure l'affirmation selon laquelle l'utilisation de n'importe quel script PHP, aussi simple soit-elle, est-elle un problème de sécurité inhérent?

Formulé de cette façon, presque aucun. Un script d'en-tête d'inclusion n'est certainement pas une vulnérabilité. Avoir PHP installé en premier lieu lorsque vous n'en avez pas besoin n'est pas la meilleure pratique de sécurité, l'avoir installé et ne pas le mettre à jour régulièrement chaque fois que des correctifs de sécurité sortent est un problème potentiel, tout comme ne pas avoir une politique de qui est responsable de ces mises à jour - après avoir terminé la conception du site, le client sera-t-il responsable de cela? Ou le fournisseur d'hébergement? Si le client s'inquiète à ce sujet, il ne devrait pas avoir PHP sur le serveur en premier lieu. Sinon, il n'y a aucune raison liée à la sécurité de ne pas l'utiliser dans des endroits où vous savez ce que vous faites.

Les langages et les outils ne sont pas intrinsèquement non sécurisés, le mauvais code et les pratiques de sécurité le sont.

Puisque php a une faible barrière à l'entrée, les personnes qui ne comprennent pas la sécurité du réseau et le codage sécurisé peuvent créer des problèmes de sécurité avec des décisions non informées.

Ce n'est pas l'outil, c'est le singe qui l'utilise ;-)

Le code écrit dans n'importe quelle langue peut ne pas être sûr.

"Ils sont réticents parce qu'ils ont été informés par leur société d'hébergement que l'utilisation de PHP est un problème de sécurité qui pourrait permettre à quelqu'un de s'introduire dans cPanel et de prendre le contrôle du site"

Si la société d'hébergement pense qu'ils besoin de cPanel pour exécuter PHP puis il est temps de déplacer l'hôte