Je suis intéressé par les commentaires et les stratégies pour protéger les fichiers de configuration PHP, en particulier ceux qui contiennent des informations d'identification de la base de données.
Le conseil habituel, qui consiste à définir l'extension du fichier à *.php, est très bien pour l'instant, mais il ne protège pas contre les attaques de type "perusal". Le scénario particulier que j'envisage :
- Nous avons un serveur qui héberge une variété d'applications tierces.
- Nous ne pouvons pas passer en revue toutes les applications
- Si un attaquant compromet une application, il peut potentiellement utiliser cette application pour lire des fichiers dans d'autres répertoires. Les fichiers de configuration de la base de données sont une cible évidente.
J'ai une solution, qui semble avoir du mérite, mais je ne suis pas entièrement à l'aise avec elle. J'aimerais entendre des commentaires à ce sujet, ainsi que sur les points suivants
- trouver ce que php_include est configuré pour
- placer le fichier de configuration dans ce répertoire
- assurez-vous que les instructions require/include qui chargent la configuration ne spécifient pas de chemin d'accès dur (pas de ./ en tête, etc.)
OBJECTIFS
-
cache complètement le fichier de configuration à une application web sœur errante (et plus important encore, au serveur web lui-même).
-
masque l'emplacement réel du fichier de configuration. Il n'est pas facile de le déterminer en lisant le code. Ceci est opposé à la spécification d'un chemin en dehors de l'arbre web.
-
une intervention minimale, tant au niveau du serveur que de l'application.
-
Évite le codage dur de la voie.
Cela ne résout pas les conflits de noms de fichiers de configuration, même si, pour certaines applications, il est probablement utile de changer le nom du fichier de configuration inclus.
Malheureusement, un grand nombre de nos applications Web semblent exiger des chemins d'accès codés en dur.
Quelles approches les autres ont-elles adoptées ?
