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:
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.
Utilisez du php durci car cela ne coûte rien et cela peut vous aider.
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.
Mod_security est un gros plus mais doit être bien utilisé et configuré.
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:
* 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.
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
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.
Suhosin a un coût de performance assez important, donc le commentaire "ne coûte rien" est un peu décalé.
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.
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.