Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
Oui mais normalement on restreint l'accès aux scripts en dev... ou alors on n'affiche les erreurs que pour le dev
C'est encore activé par défaut ces horreurs ?
ça dépend des distributions, et puis on ne sait jamais, si on arrive après un admin foireux, on pourra les trouver activées...
Ce modèle de sécurité (liste noire) est bancal à mon avis.
peut être mais on a pas le choix, et d'un autre coté ça permet d'être plus souple dans la gestion de la liste : en supprimant les fonctions à risque, on est relativement tranquille par la suite... et vu le nombre de fonctions de PHP, la lite noire sera toujours plus rapide à constituer et lire que la blanche.
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
je m'interroge sur l'utilité de remonter ça au mainteneur : si un utilisateur légitime a oublié son mot de passe : il le redemandera, les autres seront de faux utilisateurs essayant de trouver le mot de passe d'un utilisateur légitime... qu'est-ce qu'il s'en tape le mainteneur de savoir qu'un type a essayé de craquer un pass ? tant que le bloquage est efficace...
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 ?).
ça dépend de ce que tu fais avec ton "site web"... et puis pour l'utilisateur : c'est évident je pense.
De ma petite expérience, PHP souffre de plusieurs problèmes :
on est déjà au courant et c'est hors de propos : l'objet du journal n'est pas de connaître les pb de php ou d'en faire le procès ni de le comparer à d'autres langages et n'est pas non plus un appel aux trolls poilus, mais juste une demande de constitution d'une liste de choses à faire pour sécuriser php autant que faire se peut.
Tout ce que tu dis est évident et notoire, cependant même en sachant ça, on ne sait pas forcément comment se prémunir de ces risques : ce journal devrait permettre à certains de savoir comment faire, point barre.
[^] # Re: D'autres trucs
Posté par jeffcom . 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 ;-)).
Oui mais normalement on restreint l'accès aux scripts en dev... ou alors on n'affiche les erreurs que pour le dev
C'est encore activé par défaut ces horreurs ?
ça dépend des distributions, et puis on ne sait jamais, si on arrive après un admin foireux, on pourra les trouver activées...
Ce modèle de sécurité (liste noire) est bancal à mon avis.
peut être mais on a pas le choix, et d'un autre coté ça permet d'être plus souple dans la gestion de la liste : en supprimant les fonctions à risque, on est relativement tranquille par la suite... et vu le nombre de fonctions de PHP, la lite noire sera toujours plus rapide à constituer et lire que la blanche.
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
je m'interroge sur l'utilité de remonter ça au mainteneur : si un utilisateur légitime a oublié son mot de passe : il le redemandera, les autres seront de faux utilisateurs essayant de trouver le mot de passe d'un utilisateur légitime... qu'est-ce qu'il s'en tape le mainteneur de savoir qu'un type a essayé de craquer un pass ? tant que le bloquage est efficace...
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 ?).
ça dépend de ce que tu fais avec ton "site web"... et puis pour l'utilisateur : c'est évident je pense.
De ma petite expérience, PHP souffre de plusieurs problèmes :
on est déjà au courant et c'est hors de propos : l'objet du journal n'est pas de connaître les pb de php ou d'en faire le procès ni de le comparer à d'autres langages et n'est pas non plus un appel aux trolls poilus, mais juste une demande de constitution d'une liste de choses à faire pour sécuriser php autant que faire se peut.
Tout ce que tu dis est évident et notoire, cependant même en sachant ça, on ne sait pas forcément comment se prémunir de ces risques : ce journal devrait permettre à certains de savoir comment faire, point barre.