Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
register_globals = off
allow_url_fopen = off
C'est encore activé par défaut ces horreurs ?
désactiver certaines fonctions si on en a pas besoin
Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP, mais ça serait la meilleure solution.
Pour illustrer mon propros (liste blanche vs liste noire) : c'est comme les protections « anti-include ». Refuser le motif « ../ » dans un nom de fichier est insuffisant. Si l'attaquant arrive à obtenir le chemin absolu (facile en général), il pourra accéder à n'importe quel fichier. La bonne solution est d'utiliser real_path() et vérifier que le fichier (ou le chemin) est dans une liste blanche.
modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok
Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).
--
De ma petite expérience, PHP souffre de plusieurs problèmes :
* Le langage est trop laxiste, PHP devrait obliger les développeurs à corriger les erreurs. D'ailleurs, il faut beaucoup de motivation pour activer tous les avertissements et tous les corriger. Je vous déconseille de le faire sur un gros projet existant sous peine de dépression :-)
* Sites web développés par des développeurs ayant appris la programmation sur le tas (comme tout le monde) et n'ayant aucune connaissance en sécurité (comme la grande majorité des développeurs). Dans le cas de PHP, ça importe car les applications (sites web) sont accessibles depuis Internet.
* PHP et MySQL sont souvent installés avec un maximum de fonctionnalités, alors que du point de vue sécurité, il faudrait l'inverse. Exemple : allow_url_fopen activé par défaut.
* Pas de politique de sécurité globale : une faille PHP permet d'accéder à la base de données, au FTP, (parfois) aux autres sites hébergés sur le même serveur, puis à la boîte mail, etc. Un des problèmes courant est que le mot de passe est le même partout (FTP, MySQL, mail, etc.).
--
Je ne suis pas sûr que PHP soit l'origine du mal. C'est plutôt que les développeurs web débutent avec PHP. Il y a une association PHP = programmeur débutant, et donc indirectement PHP = site web peu sûr, puis PHP = langage peu sûr.
PS : Bien sûr, le langage en lui-même est vraiment une grosse merde comparés à ses concurrents (notamment Python et Ruby).
[^] # Re: D'autres trucs
Posté par Victor STINNER (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 3.
Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
register_globals = off
allow_url_fopen = off
C'est encore activé par défaut ces horreurs ?
désactiver certaines fonctions si on en a pas besoin
Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP, mais ça serait la meilleure solution.
Pour illustrer mon propros (liste blanche vs liste noire) : c'est comme les protections « anti-include ». Refuser le motif « ../ » dans un nom de fichier est insuffisant. Si l'attaquant arrive à obtenir le chemin absolu (facile en général), il pourra accéder à n'importe quel fichier. La bonne solution est d'utiliser real_path() et vérifier que le fichier (ou le chemin) est dans une liste blanche.
modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok
Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).
--
De ma petite expérience, PHP souffre de plusieurs problèmes :
* Le langage est trop laxiste, PHP devrait obliger les développeurs à corriger les erreurs. D'ailleurs, il faut beaucoup de motivation pour activer tous les avertissements et tous les corriger. Je vous déconseille de le faire sur un gros projet existant sous peine de dépression :-)
* Sites web développés par des développeurs ayant appris la programmation sur le tas (comme tout le monde) et n'ayant aucune connaissance en sécurité (comme la grande majorité des développeurs). Dans le cas de PHP, ça importe car les applications (sites web) sont accessibles depuis Internet.
* PHP et MySQL sont souvent installés avec un maximum de fonctionnalités, alors que du point de vue sécurité, il faudrait l'inverse. Exemple : allow_url_fopen activé par défaut.
* Pas de politique de sécurité globale : une faille PHP permet d'accéder à la base de données, au FTP, (parfois) aux autres sites hébergés sur le même serveur, puis à la boîte mail, etc. Un des problèmes courant est que le mot de passe est le même partout (FTP, MySQL, mail, etc.).
--
Je ne suis pas sûr que PHP soit l'origine du mal. C'est plutôt que les développeurs web débutent avec PHP. Il y a une association PHP = programmeur débutant, et donc indirectement PHP = site web peu sûr, puis PHP = langage peu sûr.
PS : Bien sûr, le langage en lui-même est vraiment une grosse merde comparés à ses concurrents (notamment Python et Ruby).