PHP fichiers consultables: est-ce une vulnérabilité?
J'ai un ami qui a un site Web développé en PHP sur lequel nous pouvons parcourir tous ses fichiers un par un (bien sûr, nous ne pouvons pas lire le contenu du PHP fichiers).
Pensez-vous que c'est une faille de sécurité? Si oui, dans quel sens?
Ce que vous décrivez est une liste de répertoires normale
En soi, la liste des répertoires n'est pas un problème de sécurité. Si la sécurité de votre système est compromise après avoir déterminé la structure de vos fichiers et répertoires, alors vous comptez sur la sécurité par l'obscurité , ce qui est mauvais. Exemples de cette mauvaise pratique:
- Utilisation de noms de répertoires secrets pour accéder aux fichiers sensibles.
- Limiter les fonctions privilégiées d'exécution pour accéder uniquement à leurs URL plutôt que d'utiliser les autorisations appropriées.
- Laisser des portes/portes arrière spéciales pour les développeurs.
Cependant , dans le cadre d'une bonne politique de sécurité, après avoir mis en place des mesures de sécurité appropriées, il est bénéfique d'obscurcir les parties actives de votre système. Moins vous montrez sur votre système, moins un attaquant peut obtenir d'informations sur vous, ce qui signifie que vous compliquez la tâche.
"Donc qu'est ce que je devrais faire?" tu demandes. Simple: désactivez la liste des répertoires dans les configurations de votre serveur Web. Dans Apache, vous accédez à votre httpd.conf et trouvez la ligne où il est dit
Options Includes Indexes
Supprimez Indexes de la ligne, puis redémarrez votre Apache.
Pour ajouter aux réponses de @adnan et @ william-calvin:
Cela "peut" être un problème;)
Il révèle des noms de fichiers qui ne sont accessibles que, par exemple, par des utilisateurs authentifiés (pensez "change_settings.php" pour les utilisateurs connectés). Maintenant, cela en soi n'est pas un problème. Si son site Web est bien écrit, il effectuera les vérifications d'autorisation appropriées avant de charger chaque fichier. D'un autre point de vue, un bon robot/araignée "cartographiera" tous les fichiers accessibles de toute façon.
S'il est en désordre avec les fichiers de sauvegarde (pensez: secret.bak ou blah.php.old), alors d'autres pourront lire ces fichiers. C'est également le cas pour les fichiers rapides phpinfo () et db_dump.sql.
Il peut inclure des fichiers et les avoir avec une extension non php, telle que db.inc, selon votre configuration Apache, un attaquant peut être en mesure de les lire.
Donc, comme expliqué par les autres - c'est une mauvaise pratique. Il donne plus d'informations que nécessaire.
Oui .. C'est définitivement un problème.
Si je connais votre structure, je pourrai mieux comprendre votre système ce qui me permettra d'attaquer plus facilement votre système.
Il est recommandé de désactiver votre liste de répertoires (Voir ceci tutoriel si vous êtes sur CPanel)
Moins les pirates le savent, plus ils ont besoin de réfléchir.
Pour ajouter à la réponse d'Adnan, certains frameworks PHP, comme PyroCMS, résolvent le problème dans votre question en utilisant une combinaison de .htaccess fichiers et ayant un fichier d'index, nommé quelque chose comme index.php, dans chaque répertoire.
Une .htaccess le fichier est comme une extension de la configuration de votre serveur dans des fichiers comme php.config, mais peuvent être inclus directement dans les dossiers du site, bien que dans certains cas, ils ne soient pas autorisés ou ne fonctionnent pas à cause des fichiers du serveur. De plus, vous pouvez les utiliser même si vous n'avez pas accès aux fichiers du serveur, par exemple si vous avez un site dans le cloud quelque part. Ils peuvent être utilisés pour limiter l'accès aux fichiers du répertoire dans lequel ils se trouvent ou des dossiers enfants. PyroCMS et d'autres frameworks ont souvent un fichier htaccess dans chaque dossier, dont beaucoup limitent ou refusent l'accès au dossier et à tous ses sous-dossiers.
index.php est l'une des pages par défaut à afficher lorsque l'URL pointe vers le dossier, bien que vous puissiez configurer ces pages par défaut dans vos fichiers serveur. Par exemple, si l'utilisateur accède à example.com/folder, et il n'y a aucun de ces fichiers par défaut dans ce répertoire, la page montrera ce que votre ami voit probablement, ce qui est probablement la vue qu'Adnan montre dans sa réponse. Cependant, s'il existe un index.php fichier dans ce dossier, la page affichera à la place ce qui se trouve dans <site folder>/folder/index.php. PHP ont souvent un index.php dans chaque ou presque chaque dossier et sous-dossier pour vous. Beaucoup de ces fichiers ont quelque chose comme:
<div>Forbidden!!!</div>
<div>Please don't go here! It's very sensitive!</div>
Comme ceux-ci .htaccess et index.php les fichiers sont déjà placés dans tous ces dossiers, vous n'avez pas à le faire vous-même, bien que vous puissiez les supprimer si vous voulez ou devez adapter votre site. Même si vous n'utilisez pas ces cadres, en télécharger un couple et voir ce qu'ils font peut être utile dans la conception de votre site. Faites attention si vous faites cela, car beaucoup d'entre eux sont des centaines de mégaoctets.
Soit dit en passant, oui, il est déconseillé de parcourir ces fichiers. Le point avec cette réponse est qu'il existe des outils que vous pouvez utiliser pour vous éviter d'avoir à répéter le code passe-partout des milliers de fois, parfois littéralement, et il se trouve que les sujets de cette question impliquent du code passe-partout avec lequel ces outils peuvent vous aider.
Oui, en ce qui concerne les réponses ci-dessus, je ne veux pas partager les mêmes informations, mais un événement réel qui est arrivé à mon organisation.
Nous avions un serveur Web (frontal dont les clients peuvent voir les informations de leur compte Internet, possibilité de recharger, etc.).
Le développeur a téléchargé un BigDump pour sauvegarder les données du serveur triple A, en ce sens qu'un attaquant a examiné l'écoute du répertoire et a trouvé un fichier de vidage contenant toutes les cartes à gratter et les informations de compte.J'espère qu'il m'a signalé et que nous avons résolu ce problème.
Comme mentionné également, en s'appuyant sur la sécurité par l'obscurité, il est préférable de désactiver l'écoute des répertoires, j'ai établi une politique pour mon organisation selon laquelle cette fonctionnalité doit être désactivée sur tous les serveurs Web.