Sécurisation des serveurs Web PHP


31

Les applications PHP sont réputées pour leurs problèmes de sécurité supérieurs à la moyenne. Quelles techniques de configuration utilisez-vous pour vous assurer que l'application est aussi sécurisée que possible?

Je recherche des idées comme:

J'utilise normalement Linux, mais n'hésitez pas à suggérer des solutions Windows également.

Réponses:


15
  1. Utilisez la directive open_basedir pour confiner vos scripts PHP dans leur répertoire personnel et les éventuels répertoires d'application supplémentaires. C'est très efficace en soi.

  2. Utilisez du php durci car cela ne coûte rien et cela peut vous aider.

  3. Utilisez suPHP pour que les scripts PHP s'exécutent en tant que propriétaire du fichier (un utilisateur par site Web) et évitez d'utiliser des fichiers avec de mauvaises autorisations comme 777 ... suPHP peut également vous permettre d'avoir sur php.ini par site Web afin qu'un site soit stupide l'exigence ne détruit pas tout.

  4. Mod_security est un gros plus mais doit être bien utilisé et configuré.


Certains mauvais sites ont en fait besoin de register_globals et de fopen, c'est pourquoi vous utilisez un php.ini par site avec suPHP. Un site peut simplement devenir kamikaze et les autres être (presque) parfaitement sûrs.
Antoine Benkemoun

4
S'ils utilisent register_globals et fopen, cela suggère que la qualité est si mauvaise que vous voudrez peut-être reconsidérer leur utilisation :)
David Pashley

S'ils paient 150 € / mois, vous ne reconsidérez pas.
Antoine Benkemoun

3

D'après mon expérience, la plupart des vulnérabilités sur un site Web basé sur PHP sont le résultat d'une mauvaise conception (du site), plutôt que de défauts dans PHP lui-même.

Quelques conseils rapides:

  • Filtre universellement entrée, sortie d'échappement. Clarificaiton: filtrer ne signifie pas échapper, cela signifie "si je trouve quelque chose de louche dans cette entrée utilisateur, entraîner l'échec de la soumission et dire à l'utilisateur de reformater."
  • Plutôt que d'utiliser escapeshellcmd (), ne permettez simplement à aucune entrée utilisateur d'être exécutée dans le shell . C'est dangereux et probablement jamais vraiment nécessaire.
  • N'appelez pas de fonctions comme phpinfo () sur un site de production (ou si vous le faites, voir ci-dessous *).
  • Lors de la conception d'une application Web, pensez toujours "est-ce un vecteur d'attaque possible?" Disons, injection SQL. Si la réponse est «oui», branchez-la immédiatement - ne dites pas «ok, j'ajouterai cela plus tard dans le développement en tant que fonctionnalité». La sécurité n'est jamais une caractéristique.
  • Ne jamais afficher d'erreurs brutes à l'utilisateur; cela signifie que la valeur display_errors de php.ini = Off, log_errors = On. Piège les erreurs d'exécution et produit quelque chose de joli. Prenons l'exemple de la baleine de Twitter: elle ne donnera pas d'informations de niveau de débogage à l'utilisateur, elle dit simplement "woops, quelque chose s'est cassé, veuillez rafraîchir".

* Vous pouvez également jeter un coup d'œil à un court article que j'ai écrit intitulé "Sécuriser phpinfo (), en quelque sorte" et assurez-vous de lire les commentaires http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ C'était une idée rapide que je devais (quelque peu) protéger phpinfo () si j'avais oublié de le supprimer sur un site de production.

De manière plus générale, certains développeurs écrivent des wrappers pour les fonctions sensibles qui vérifient si l'indicateur "site de production" n'est pas défini ou non, et désactive la fonction sensible en production.


Ma question était plutôt de savoir comment protéger votre serveur contre un PHP mal écrit. :) Je ne voulais pas dire que PHP lui-même n'était pas sûr, plus qu'il attirait des développeurs moins expérimentés et que la bibliothèque standard les obligeait à se rappeler de protéger chaque appel, plutôt que la bibliothèque protégeant tous les utilisateurs. +1 car c'est une réponse très utile.
David Pashley

J'ai eu cette impression et j'ai répondu en conséquence :) Merci pour le commentaire! Je ne peux pas entrer dans le détail ici, évidemment, mais ce sont de grosses fosses. Si vous avez des questions plus spécifiques, vous pouvez sûrement les poser sur Stack Overflow et moi et tout le monde y contribuerons. (Et pour ce que ça vaut, je suis un ZCE).
msanford

3

Autres paramètres qui devraient être modifiés pour durcir le PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Stockez toutes les erreurs PHP dans le fichier /var/log/phperror.log :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

1

J'ai ajouté les référentiels dotdeb à mon /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Comme ils corrigent php / apache / mysql beaucoup plus fréquemment que Debian.


1

Envisagez une configuration open_basedir"par site". open_basedirest un paramètre php.ini qui empêchera vos scripts d'accéder à des fichiers en dehors d'une liste blanche définie. Si votre serveur héberge plusieurs sites, cela empêchera un site de lire les paramètres de la base de données d'un autre site. Cela empêchera également un script php d'accéder / de modifier les fichiers système principaux. Open basedir est facile à configurer, il suffit d'ajouter la ligne " php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list" à chaque vhost Apache.

Pensez également à désactiver le moteur de script PHP pour tous les sites / dossiers qui ne devraient pas contenir de scripts PHP (par exemple, un dossier d'images téléchargées). Encore une fois, c'est simple, ajoutez "php_admin_value engine off" à tous les Apache VirtualHosts qui n'ont pas besoin de php. Pour désactiver PHP dans un répertoire, mettez la même chose dans une balise Directory.

Exécutez les autorisations de fichier aussi serrées que possible, évitez l'accès en écriture aux scripts PHP pour l'utilisateur Apache, cela empêche un script en cours d'exécution de se modifier lui-même ou d'autres scripts sur le même site / serveur. Évitez autant que possible les autorisations 777, déterminez les autorisations minimales requises pour exécuter l'application et les utiliser.

Si vous hébergez plusieurs sites, chacun avec sa propre base de données, utilisez un utilisateur MySQL / Postgres distinct pour chacun, et définissez des autorisations sur chaque utilisateur de sorte qu'ils n'aient accès qu'aux bases de données pertinentes. Encore une fois, cela empêchera un script non autorisé d'altérer la base de données d'une autre application.

Suosin, HardenedPHP, mod_security et similaires sont également précieux, mais utilisez-les en plus d'une configuration étroitement verrouillée, pas à la place de.


0

Suhosin a un coût de performance assez important, donc le commentaire "ne coûte rien" est un peu décalé.


2
À quoi sert un site Web rapide et piraté? :) hardened-php.net/suhosin/benchmark.html suggère une baisse de 8,85% sur une référence. Cela peut être acceptable pour les avantages de sécurité qu'il offre. Cela aurait probablement dû être un commentaire plutôt qu'une réponse.
David Pashley

Suhosin protège principalement contre les attaques locales. Donc, si vous partagez votre serveur avec des personnes en qui vous n'avez pas confiance, cela peut valoir le coup. Si vous avez votre propre serveur ou votre propre tranche vm, je ne vois pas l'intérêt.

0

Recherchez-vous des suggestions de base de pare-feu / topologie? J'aime l'idée d'utiliser des choses comme la livre pour empêcher l'accès directement au serveur Web PHP à partir des internets non lavés. De cette façon, vous pouvez également séparer le serveur Web des autres parties de votre réseau.


Non, je cherche des moyens d'améliorer la sécurité du runtime PHP.
David Pashley

0

L'utilisation de Suhosin / mod_security / SuPHP rendra certainement votre serveur PHP sécurisé. La désactivation de certaines fonctions comme exec, passthru, system et escapeshellcmd aidera également beaucoup.


1
Escapeshellcmd () n'est-il pas juste utilisé pour échapper une chaîne? Il ne fournit aucun moyen d'exécuter un processus. Comment quelqu'un pourrait-il l'utiliser pour causer un problème?
David Pashley
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.