En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?
Parce que le safe mode est tout sauf safe et introduit même de l'insécurité... en plus du fait que certains se permettent n'imp sous prétexte qu'ils sont en safe-mode...
Le expose_php et display_errors à off permettent simplement de ne pas donner trop d'infos concernant la configuration du serveur, ça évite, par exemple, que des robots scanent les page d'un serveur à la recherche d'une version de php ou d'une appli web particulière connue pour avoir telle et tell faille. Ça n'est pas, en soi un rempart infranchissable, mais ça permet d'éviter d'être trop facilement repéré.
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
Le but de la manœuvre étant de ne pas afficher les erreurs pour le quidam ou simplement l'utilisateur final mais permettre aux mainteneurs d'avoir un retour en cas d'erreur, voire un meilleur retour : inscription dans une bdd des données utiles (utilisateur identifié, page, variables de session et tout ce qui peut être utile au debug) voire alerte plus importante dans le cas ou telle ou telle erreur survient sur tel ou tel script.
Évidemment, c'est comme tout, quand on sait pas faire : vaut mieux ne pas faire... si on garde ça en tête, on devrait éviter certaines grosses failles...
Si on va dans ce sens, la meilleur façon de ne pas avoir d'emmerde : c'est ne pas héberger de site web...
[^] # Re: D'autres trucs
Posté par jeffcom . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
Parce que le safe mode est tout sauf safe et introduit même de l'insécurité... en plus du fait que certains se permettent n'imp sous prétexte qu'ils sont en safe-mode...
Le expose_php et display_errors à off permettent simplement de ne pas donner trop d'infos concernant la configuration du serveur, ça évite, par exemple, que des robots scanent les page d'un serveur à la recherche d'une version de php ou d'une appli web particulière connue pour avoir telle et tell faille. Ça n'est pas, en soi un rempart infranchissable, mais ça permet d'éviter d'être trop facilement repéré.
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
Le but de la manœuvre étant de ne pas afficher les erreurs pour le quidam ou simplement l'utilisateur final mais permettre aux mainteneurs d'avoir un retour en cas d'erreur, voire un meilleur retour : inscription dans une bdd des données utiles (utilisateur identifié, page, variables de session et tout ce qui peut être utile au debug) voire alerte plus importante dans le cas ou telle ou telle erreur survient sur tel ou tel script.
Évidemment, c'est comme tout, quand on sait pas faire : vaut mieux ne pas faire... si on garde ça en tête, on devrait éviter certaines grosses failles...
Si on va dans ce sens, la meilleur façon de ne pas avoir d'emmerde : c'est ne pas héberger de site web...