La société d'hébergement nous a conseillé d'éviter PHP pour des raisons de sécurité. Est-ce vrai?
Je fais une refonte pour un client qui est naturellement préoccupé par la sécurité après avoir été piraté dans le passé. J'avais initialement suggéré d'utiliser un simple PHP include pour les modèles d'en-tête et de pied de page et un formulaire de contact qu'ils voulaient. Ils hésitent car ils ont été informés par leur hébergeur que l'utilisation de PHP est un problème de sécurité qui pourrait permettre à quelqu'un de pénétrer dans cPanel et de prendre le contrôle du site.
Pour moi, cela revient à dire à quelqu'un de ne jamais conduire pour éviter tout accident de voiture. Mon instinct est que l'hôte essaie de rejeter la faute sur le client pour les failles de sécurité dans son propre système. De plus, le serveur a toujours PHP installé, que nous l'utilisions ou non, donc je me demande dans quelle mesure cela réduit réellement la surface d'attaque ... Mais puisque je ne suis pas un expert en sécurité , Je ne veux pas mettre mon pied dans ma bouche.
J'ai dit à mon client que pour traiter le formulaire de contact, il allait avoir besoin d'une forme de script dynamique. (Faux?) Ils ont demandé si je pouvais simplement utiliser PHP sur cette seule page. Est-ce que cela serait mesurablement plus sûr, ou est-ce l'équivalent de verrouiller les portes de votre voiture et de laisser la fenêtre baissée?)
Quelle est la vérité de l'affirmation selon laquelle l'utilisation de tout PHP, aussi simple soit-il, est une sécurité inhérente problème? Nous sommes sur l'hébergement partagé sans SSL. Est-il raisonnable de supposer que nous avons été piratés en raison de l'utilisation de PHP? Serons-nous plus sûrs si nous ne l'utilisons pas, mais ne pouvons pas le désinstaller? Parce que sinon, nous avons d'autres problèmes.
(La réponse serait-elle différente pour toute autre langue?)
Ce n'est pas tant que PHP lui-même a des problèmes de sécurité (en supposant les mises à jour de sécurité nécessaires), car il existe de nombreux logiciels PHP populaires avec des problèmes de sécurité effrénés. Vous pourriez reprocher à PHP d'être un langage qui vous donne suffisamment de corde pour vous étouffer, mais le vrai problème est à quel point le code PHP est réellement vulnérable. Il suffit de chercher la balise Stack Overflow PHP pour trouver PHP débutants écrivant du code horriblement vulnérable basé sur une atrocité d'un ancien tutoriel.
De plus, un nombre important de logiciels PHP populaires connus pour leurs failles de sécurité rampantes sont basés sur un code et des pratiques de codage très anciens . Beaucoup de ces anciennes pratiques sont considérées comme de mauvaises pratiques en raison de problèmes de sécurité inhérents.
Pour moi, cela revient à dire à quelqu'un de ne jamais conduire pour éviter tout 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 faute sur le client pour les failles de sécurité dans son propre système.
Pas nécessairement. Si un utilisateur utilise le même mot de passe pour le site WordPress et cPanel, la compromission du mot de passe WordPress compromet également cPanel. Ce serait la faute de l'utilisateur. Les pirates ont rarement besoin d'aller aussi loin et utilisent simplement un PHP Shell.
J'ai dit à mon client que pour traiter le formulaire de contact, il allait avoir besoin d'une forme de script dynamique. (Faux?)
Pas nécessairement vrai. Vous pouvez utiliser un service tiers pour gérer l'envoi de courrier. Ensuite, le service gère les scripts de serveur dynamique et prend en charge les implications de sécurité. Il existe de nombreux services de ce type disponibles avec différents ensembles de fonctionnalités, et ils sont populaires pour alimenter les formulaires de contact sur des sites générés statiquement.
Quelle vérité y a-t-il à affirmer que l'utilisation d'un script PHP, aussi simple soit-il, est un problème de sécurité inhérent?
Certains, mais pas beaucoup. PHP implique un code actif, à la fois PHP et le logiciel serveur qui l'exécute. S'il y avait une vulnérabilité 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 ne possède pas.
"Bien" n'est peut-être pas le bon mot, mais "sage", "prudent" et "consciencieux" me vient à l'esprit. PHP a, depuis sa création, adhéré à une philosophie qui dévalue l'exactitude dans les logiciels. Il existe un grand nombre de situations qu'un programme peut rencontrer dans lesquelles d'autres langages (par exemple Python) abandonneraient et lanceraient une erreur pour vous dire que votre programme est incorrect, mais PHP choisit plutôt de faire quelque chose de non-sens et de continuer comme si les choses allaient bien.
Gardez à l'esprit que l'exactitude est très important pour la sécurité. Un langage qui a tendance à ignorer silencieusement les erreurs de gauche et de 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 que vos programmeurs pensent protéger contre une certaine attaque, mais en fait est ignoré parce que l'interpréteur ignore une erreur.
En plus:
- PHP est conçu pour faire appel au plus petit dénominateur de programmeurs ayant le moins de motivation pour devenir bon dans leur métier. Et donc les plus susceptibles d'écrire des logiciels non sécurisés.
- L'équipe PHP a un historique de tentatives profondément erronées pour résoudre les problèmes de sécurité courants. Regardez par exemple la protection par injection SQL, qui trahit les tentatives répétées et défectueuses de résoudre le problème:
real_escape_string(car l'originalescape_stringétait cassé, mais ils ne l'ont supprimé que plus tard) vsaddslashesvs.mysql_escape_string/pg_escape_stringetc. Alors que pratiquement tous les autres langages sont simplement allés avec 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.
Donc, pour toutes les discussions dans d'autres réponses sur la façon dont vous pouvez écrire un logiciel sécurisé en PHP, si vous l'essayez, vous nagez à 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
En ce moment, Statistiques Wordpress montre que plus de la moitié de tous les utilisateurs exécutent PHP sur les versions de PHP qui sont passées - Fin de vie (PHP 5.2 - 5.4). En deux semaines, PHP 5.5 passe en fin de vie, puis il passe à environ 80% de toutes les installations. Maintenant, pour être juste, certaines installations Enterprise/LTS Linux rétroportent des 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 à niveau PHP Soit ils ne peuvent pas/ne mettront pas à jour leur code, soit ils pensent que les anciens logiciels sont plus stables.
Wordpress (# 1 PHP application utilisée dans le monde entier) a fait un effort concerté pour s'assurer que les utilisateurs restent à jour sur le logiciel lui-même (et ils ont fait de grands progrès), mais malgré cela, seulement 40 % utilisent la dernière version de Wordpress. Cela signifie que 60% peuvent avoir une vulnérabilité de sécurité non corrigée. Et ce n'est que le programme de base. Wordpress possède un écosystème massif de plugins, et beaucoup d'entre eux - ont leurs propres failles de sécurité .
Ensuite, il y a d'autres problèmes, comme beaucoup de code plus ancien utilisant la défunte bibliothèque mcrypt . Et ce n'est qu'un seul PHP plugin que vous pouvez compiler.
Maintenant, extrapolez ceci aux serveurs qui ne fonctionnent pas et qui rapportent les statistiques à WP. Il ne peint pas une jolie image. 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 vieux qu'il avait SSLv2 activé ...
Mauvaises pratiques
Si vous traînez SO PHP questions assez longtemps, vous verrez beaucoup de gens pratiquer un mauvais code. Certains des problèmes que j'ai vus sur le années
- Injection SQL
- Penser MD5 est un bon moyen de protéger les mots de passe
- Utiliser des API obsolètes dans leur code (c'est-à-dire
ext/mysql, l'ancien connecteur MySQL) - Faire confiance à l'entrée 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 PHP (c'est-à-dire la fonction exec )
Pour les non-formés, cela ressemble à un problème PHP, quand ce sont les codeurs et leurs écosystèmes qui causent les problèmes. Peut-être qu'ils étaient pressés. Peut-être qu'ils ont embauché un gars qui fait cela à sa place. temps et "juste fait fonctionner".
Peut-il être sécurisé?
OUI! Mais cette sécurité nécessite un certain effort. Gardez votre PHP installation à jour. Heck, gardez votre serveur entier à jour. L'hôte ne fera pas la sécurité et les correctifs? Trouvez un autre hôte. (Je suis étonné par les gens qui rechignent à cela.) Construisez votre propre serveur (les machines virtuelles sont bon marché). Mais surtout, faites attention. Apprenez tout ce que vous pouvez sur la sécurité. Ne vous contentez pas laissez votre site Web et votre serveur prendre la mer.
Quelqu'un qui vous dit PHP n'est pas sûr est juste paresseux.
PHP n'est pas moins, ni plus sûr, ni moins sûr que n'importe quel autre langage (Java, Rails, etc.). C'est une question de codage. Des freins et contrepoids sont-ils en place pour dévier, 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 à l'aide de .NET, Java, ASP, PHP, Cold Fusion et Perl. Les langues les plus utilisées étaient .NET (28,1% des applications Web), Java (24,9%) et ASP (15,9%)).
...
Le langage de programmation .Net avait une moyenne de 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 écrites dans la langue ainsi que la complexité des sites Web doivent être considérés comme un facteur contributif", a déclaré 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 preniez des programmeurs non qualifiés (faute de meilleurs termes) dans chaque langue, ces chiffres pourraient être inversés et Perl pourrait avoir le plus de vulnérabilités, .Net 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 la falsification/l'abus testé avant d'être mis au point?
Il y a beaucoup de sécurité feuilles de triche , guides de bonnes pratiques , et d'autres articles qui couvrent 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 un "il a dit", a-t-elle dit, une sorte de lutte pour convaincre votre client de vous permettre de créer le site en utilisant 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) contre pour vérifier les défauts. 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 pour le client, et créer de telle manière (PDF, etc.) qu'il est présentable au fournisseur.
L'un des problèmes fondamentaux avec PHP est vraiment un problème fondamental avec le modèle de choses CGI (sur lequel PHP est basé, malgré les pièges de mod_php) - à savoir celui face à l'utilisateur les données sont entremêlées avec des scripts, et cela devient très facile, 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; de nombreux problèmes de sécurité des plugins WordPress viennent de cet aspect, par exemple.
Les déploiements traditionnels basés sur CGI ont historiquement atténué ce problème en autorisant uniquement les scripts CGI à 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 plus de "commodité", et cette même commodité est omniprésent dans PHP.
De nombreuses applications modernes basées sur PHP utilisent souvent .htaccess Comme mécanisme de routage des requêtes rapide et sale qui aide à atténuer ces problèmes, mais ce n'est pas universel et ce n'est toujours pas un remède facile.
À mon avis, le plus gros problème avec PHP est simplement qu'il est si facile de rendre le code arbitraire PHP disponible pour s'exécuter sur n'importe quel serveur où il est configuré, et donc pendant que le code écrit en PHP n'est pas nécessairement plus ou moins sécurisé que le code écrit dans d'autres langages (bien que sa bibliothèque standard ne fait pas vraiment de faveur quand il s'agit d'écrire du code sécurisé), le mécanisme par lequel PHP l'exécution des scripts présente un énorme défi de sécurité au mérite que PHP soit 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 à PHP pour la même raison que WordPress est considéré comme un risque pour la sécurité. C'est à la mode. Plus quelque chose est répandu, plus d'énergie est investie dans le développement d'exploits.
Cela dit, je n'éviterais pas PHP s'il est correctement implémenté, 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 des risques de sécurité indépendants de la plate-forme. La modification des 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é n'est pas d'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 en incluant un modèle n'est pas stupide à moins que vous analysiez le nom du fichier à partir d'un paramètre d'URL.
Le formulaire de contact aura besoin d'une sorte d'API et d'une base de données pour gérer la demande POST lorsque quelqu'un la soumet et c'est à quel point cette partie est écrite qui va faire ou défaire des choses - quelle que soit la langue que vous utilisez utiliser, 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 en quelque sorte répercutée sur lui ou sur le client dans une page Web, l'injection de script (Java) doit être prise en compte et tout correctement HTML - Par rapport au formulaire de contact, l'utilisation d'une inclusion est aussi sûre que possible.
Si vous ne vouliez qu'un ensemble de pages Web, pas une application Web interactive, le summum de la 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.
Donc:
Quelle est la vérité de l'affirmation selon laquelle l'utilisation d'un script PHP, aussi simple soit-il, est un problème de sécurité inhérent?
Formulé de cette façon, presque aucun. Un script d'inclusion d'en-tête 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 sortie de correctifs de sécurité est un problème potentiel, comme ce n'est pas le cas). avoir une politique qui est responsable de ces mises à jour - une fois la conception du site terminée, le client sera-t-il en charge? Ou le fournisseur d'hébergement? Si le client est inquiet à 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.
Étant donné que 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 être non sécurisé.
"Ils sont réticents car leur hébergeur les a informés que l'utilisation de PHP est un problème de sécurité qui pourrait permettre à quelqu'un de pénétrer dans cPanel et de prendre le contrôle du site"
Si la société d'hébergement pense avoir besoin de cPanel pour exécuter PHP alors il est temps de déplacer l'hôte