PHP est-il sécurisé?

Question

Je suis un peu nouveau dans le codage PHP et je suis conscient que des utilisateurs malveillants peuvent pirater un site Web si vous n'avez pas désinfecté votre code PHP. Ce que je me demande, c'est s'ils ont besoin d'une boîte de saisie de données (comme pour les soumissions de fichiers ou des champs de saisie de nom d'utilisateur / mot de passe)?.

Les commandes comme "include (header.php)" nécessitent-elles également une sorte de sécurité ou sont-elles intrinsèquement sûres?

Answer 1

Comme tout autre langage, le code PHP est aussi sécurisé que le programmeur l'écrit.

Comme dans toute autre langue, les risques de sécurité individuels (et même courants) sont trop nombreux et détaillés pour être inclus dans une réponse StackOverflow.

Trouvez un livre qui couvre le codage PHP sécurisé.

Answer 2

Ne faites pas confiance à l'utilisateur.

 include "a/literal/file.php";
 

est assez sûr

 include $someFile;
 

signifie que vous voulez réfléchir à la façon dont $ someFile est défini. Si vous utilisez des données qui vous ont été fournies par un utilisateur pour définir la valeur de $ someFile, vous feriez mieux de les nettoyer.

Answer 3

Pour citer RSnake à partir d'un sla.ckers.org message de retour en 2006:

Je pensais que ce qui était intéressant, c'est que Stefan Esser à la retraite à partir de l'PHP équipe de réponse aux incidents. Ne pas commencer une guerre de religion sur les planches, mais il est intéressant de noter que le fondateur de PHP à la sécurité de l'équipe d'intervention est marre de l'absence de sécurité en PHP et fermer de suite. Son site est down en ce moment (trafic d'inondation?): [blog.php-security.org] voici Donc un couper-coller de la mémoire cache:

Samedi, Le 9 Décembre. 2006

Hier soir, j'ai enfin pris sa retraite de l'PHP Équipe chargée de la Sécurité, qui a été au départ, mon idée il y a quelques années.

Les raisons à cela sont nombreuses, mais la plus importante est que j'ai réalisé que toute tentative pour améliorer la sécurité de PHP à partir de l'intérieur est futile. Le PHP Group va sauter dans votre bateau dès que vous essayez de blâmer PHP sur les problèmes de sécurité sur l'utilisateur, mais le moment de critiquer la sécurité de PHP lui-même vous devenu persona non grata. J'ai arrêté de compter le temps, j'ai été appelé immoral traître à la divulgation des failles de sécurité en PHP ou pour le développement de Suhosin.

Pour l'ordinaire PHP utilisateur cela signifie que je n'ai plus de cacher le temps de réponse à des trous de sécurité dans mon avis. Cela signifie aussi que certains de mes avis sans correctifs disponibles, parce que le PHP Équipe chargée de la Sécurité a refusé de les corriger pendant des mois. Cela signifie aussi qu'il y aura beaucoup plus d'avis sur les failles de sécurité de PHP.

Posté par Stefan Esser en PHP, de la Sécurité à 10:58

Eh bien, effrayant que cela puisse paraître, je suis vraiment heureux d'obtenir enfin la "vraie affaire" sur PHP de sécurité. J'ai toujours été un peu méfiant, et il sera intéressant de voir ce que Stefan a à dire.

source: http://sla.ckers.org/forum/read.php?2,3976

Qui introduit bien l'Trempé projet PHP Suhosin http://www.hardened-php.net/suhosin/ et Esser Mois de PHP Bugs projet http://www.php-security.org/

Answer 4

PHP est aussi sûr que n'importe quoi. Mais pas par défaut, il s'appuie sur les compétences du programmeur. Contrairement à .NET qui tend à aider à la sécurité par défaut.

Les inclusions sont sûres, soyez prudent si les chemins sont générés de manière dyanmique.

Ce qui suit est inoffensif (selon le code dans myfile.php)

 include("mypath/myfile.php");
 

Answer 5

D'accord avec tout le monde ici - PHP n'est pas vraiment plus ou moins sûr en soi que n'importe quel autre langage.

Vous devriez cependant regarder en profondeur votre fichier php.ini . Vous devriez probablement vous renseigner sur toutes les directives. C'est là que beaucoup de gens font des erreurs dès le début.