Question:
Fichiers PHP navigables: est-ce une vulnérabilité?
user45139
2014-04-24 14:20:54 UTC
view on stackexchange narkive permalink

J'ai un ami qui a un site web développé en PHP sur lequel on peut parcourir tous ses fichiers un après un (bien sûr, on ne peut pas lire le contenu des fichiers PHP).

Est-ce que vous pense que c'est une faille de sécurité? Si oui, dans quel sens?

Je voudrais juste ajouter un point. Bien que ce ne soit pas une grande vulnérabilité, il est mauvais d'afficher une simple liste de répertoires à l'utilisateur. Si vous avez un site Web qui a un tas de widgets profilés (par exemple à "example.com/widgets/a" ou "example.com/widgets/b"), il est préférable d'afficher votre propre liste de ressources (avec la recherche , et peut-être une courte introduction aux widgets) sur "example.com/widgets/". Une liste de répertoires unix contiendra probablement un tas de fichiers PHP qui n'ont aucun sens pour l'utilisateur final. Hors sujet dans ce forum, mais c'est pourquoi c'est un commentaire et non une réponse.
Six réponses:
Adi
2014-04-24 14:41:30 UTC
view on stackexchange narkive permalink

Ce que vous décrivez est une liste de répertoires normale

enter image description here

En soi, la liste de 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, 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.
  • Limitation des fonctions d'exécution privilégiées pour accéder uniquement à leurs URL plutôt que d'utiliser les autorisations appropriées.
  • Laisser des portes / portes dérobées spéciales aux développeurs.

Cependant , dans le cadre d'une bonne politique de sécurité, après en mettant en œuvre des mesures de sécurité appropriées, il est avantageux de masquer les parties fonctionnelles de votre système. Moins vous en montrez à propos de votre système, moins un attaquant peut obtenir d'informations sur vous, ce qui signifie que vous rendez son travail plus difficile.

"Alors, que dois-je faire?" tu demandes. Simple: désactivez la liste des répertoires dans les configurations de votre serveur Web. Dans Apache, vous allez dans votre httpd.conf et trouvez la ligne où il est dit

  Les options incluent les index  

Supprimer Indexes à partir de la ligne, puis redémarrez votre apache.

Bonne réponse, bien qu'une alternative à la désactivation des index (qui peut avoir des implications fonctionnelles) consiste simplement à ajouter un fichier factice index.html / index.php
@symcbean C'est ** si ** le serveur est configuré pour utiliser ces fichiers comme fichiers d'index. Cependant, la plupart du temps, c'est activé par défaut. Donc, je suis d'accord que c'est un bon conseil.
Il est important de ne pas afficher le contenu du répertoire. Un site Web a été détourné parce qu'un utilisateur ennuyé a parcouru la liste du répertoire php, essayant de transmettre des valeurs aléatoires aux scripts et a trouvé une faille de sécurité majeure dans un script deleteuser qui supprimait toujours l'ID utilisateur passé sans vérifier les droits administratifs - donc l'utilisateur du site Web la base était partie en une heure.
D'accord Défense en profondeur = bon, sécurité à travers l'obscurité = mauvais. Cela dit, personne ne pense vraiment que c'est une ** bonne ** idée d'exposer gratuitement la structure et éventuellement le contenu de vos fichiers de code source, non? C'est génial que vous ne puissiez pas lire le contenu des fichiers PHP. Mais si vous pouvez voir les noms et les chemins de ces fichiers, qui peuvent inclure des fichiers de configuration ou d'autres fichiers plus sensibles, à quel point est-il difficile de supposer qu'ils se trouvent dans / var / www / http ou / var / www / https et d'utiliser ces informations pour essayer de les exposer à travers un autre trou ou exploiter que vous avez accidentellement laissé ouvert ou que vous ne connaissez pas?
* Une partie * de la stratégie de défense en profondeur est que vous rendez le travail assez difficile pour les méchants que cela ne vaut pas leur temps, et ils passeront à autre chose. Plus vous agitez des objets brillants devant leurs visages, plus vous rendez vos atouts intéressants et plus il est probable qu'ils dépenseront une quantité excessive d'essais pour comprendre comment casser votre système. Plus ils passent de temps à essayer, pire c'est pour vous ...
@symcbean Veuillez également noter que si vous choisissez d'utiliser les fichiers `index.html`, vous devrez le faire dans chaque répertoire ** chaque **.
@Craig Merci pour votre contribution. J'ai modifié la réponse avec une meilleure formulation pour cette partie.
Oui, je n'ai pas discuté des tenants et aboutissants de l'utilisation de la négociation de contenu comme solution alternative - la plupart d'entre eux devraient être évidents pour un administrateur de serveur Web - j'essayais simplement de souligner que c'était une option.
Souvent, cPanel stockera un fichier `error_log` dans la racine Web de votre application ... le serveur Web ne l'interprétera * pas * comme les fichiers` .php`. Ce serait trop donner!
Vous devez vous assurer que vous configurez le serveur Web pour NE PAS servir ce fichier, ou que vous définissez des autorisations pour que le serveur Web ne puisse pas le lire, ou quelque chose. Quiconque peut deviner que vous êtes sur un système exécutant cPanel pourrait facilement deviner qu'un fichier portant ce nom peut exister, que vous autorisiez ou non la liste des répertoires.
J'ajouterais que même si la liste «peut ne pas» exposer des vulnérabilités, si vous avez une liste de fichiers, vous pouvez essayer de leur lancer des paramètres et des en-têtes aléatoires et voir comment ils répondent. Il est beaucoup plus facile de pirater un serveur lorsque vous connaissez les noms de fichiers susceptibles de répondre aux scripts. De plus, si vous avez quelque chose comme "phpinfo.php", vous pourriez exposer beaucoup de données de configuration, y compris éventuellement des informations sensibles. En outre, on pourrait regarder d'autres scripts et voir s'il y a quelque chose qui peut faire écho aux fichiers, etc. Les chances sont, si vous obtenez une liste, il y a aussi une autre sécurité mal configurée.
D'après moi, la sécurité par l'obscurité ne fait rien en théorie. Cependant, le montant que vous obtenez du point de vue pratique pour faire quelque chose d'aussi simple que de désactiver la liste des répertoires en vaut la peine. Techniquement, si j'avais une application parfaitement sécurisée, je serais en mesure de révéler mon code source complet à tout le monde et cela ne devrait pas avoir d'importance. En réalité, nous n'envisagerions jamais de faire cela! Révéler la structure de votre répertoire est un problème similaire à celui de la source. Ne fais pas ça
ndrix
2014-04-24 15:46:45 UTC
view on stackexchange narkive permalink

Pour ajouter aux réponses de @adnan et @ william-calvin:

Cela "peut" être un problème;)

  1. Cela révèle des noms des fichiers qui ne sont accessibles que par, par exemple, les utilisateurs authentifiés (pensez à "change_settings.php" pour les utilisateurs connectés). Or, ce n'est pas un problème en soi. Si son site Web est bien écrit, il effectuera des vérifications d'autorisation appropriées avant de charger chaque fichier. D'un autre point de vue, un bon crawler / spider "mappera" tous les fichiers qui sont accessibles de toute façon.

  2. 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 .

  3. Il peut inclure des fichiers, et les avoir avec une extension non-php, comme db.inc, en fonction de 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 qu'il ne le devrait.

Il en va de même pour les journaux que le site Web peut créer.
William Calvin
2014-04-24 14:32:27 UTC
view on stackexchange narkive permalink

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 la liste de vos répertoires (voir ce tutoriel si vous êtes sur CPanel)

Moins les pirates informatiques en savent, plus ils ont besoin de réfléchir.

Vrai.Cependant, vous devez pouvoir disposer d'un système sécurisé même dans une situation où la structure des répertoires est bien connue.Pensez aux projets open-source où cela fait partie des connaissances courantes (par exemple, wordpress).
trysis
2014-04-24 20:11:03 UTC
view on stackexchange narkive permalink

Pour ajouter à la réponse d'Adnan, certains frameworks PHP, comme PyroCMS, résolvent le problème de votre question en utilisant une combinaison de fichiers .htaccess et en ayant un fichier d'index, nommé quelque chose comme index .php , dans chaque répertoire.

Un fichier .htaccess 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 dans le répertoire dans lequel ils se trouvent ou dans les 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 qu'il n'y a aucun de ces fichiers par défaut dans ce répertoire, la page affichera ce que votre ami verra probablement, ce qui est probablement la vue qu'Adnan affiche dans sa réponse. Cependant, s'il y a un fichier index.php dans ce dossier, la page affichera à la place tout ce qui se trouve dans <site folder> / folder / index.php . Les frameworks PHP ont souvent un index.php dans chaque ou presque tous les dossiers et sous-dossiers pour vous. Beaucoup de ces fichiers ont quelque chose comme:

  <div>Forbidden !!! < / div> <div>Veuillez ne pas aller ici! C'est très sensible! < / div>  

Comme ces fichiers .htaccess et index.php sont déjà placés dans tous ces dossiers, vous n'avez pas à le faire vous-même, même si vous pouvez les supprimer si vous voulez ou devez adapter votre site. Même si vous n'utilisez pas finalement ces frameworks, en télécharger quelques-uns 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 font des centaines de mégaoctets.

Au fait, oui, c'est une mauvaise pratique d'avoir ces fichiers navigables. 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 standard des milliers de fois, parfois littéralement, et il se trouve que les sujets de cette question impliquent un code standard avec lequel ces outils peuvent vous aider.

Akam
2014-04-24 21:52:56 UTC
view on stackexchange narkive permalink

Oui, en ce qui concerne les réponses ci-dessus, je ne souhaite pas partager les mêmes informations, mais un événement réel qui est arrivé à mon organisation.

Nous avions un serveur Web (frontal duquel les clients peuvent voir leur informations de compte Internet, possibilité de recharger, etc.).

Le développeur a téléchargé un BigDump pour sauvegarder les données du serveur triple A, pendant ce temps, un attaquant a examiné le répertoire à l'écoute et a trouvé un fichier de vidage contenant toutes les cartes à gratter et les informations de compte, espérons-le, il m'a signalé et 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 d'annuaire, j'ai établi une politique pour mon organisation que cette fonctionnalité doit être désactivé sur tous les serveurs Web.

Dr. Abhishek Ghosh
2014-04-25 19:02:39 UTC
view on stackexchange narkive permalink

BTW, il n'y a pas de httpd.conf dans Ubuntu (actuellement sur 14.04; ne le recherchez pas, vous éditerez le fichier apache2.conf ).

Pour enregistrer votre site Web piloté par PHP à partir des scripts kiddies, vous pouvez lire mon long tutoriel pour durcir WordPress (j'ai fourni un lien pour la protection des droits d'auteur et vous en saurez probablement plus sur des vulnérabilités inconnues points). WordPress n'est qu'un exemple, en fait le contenu est applicable à n'importe quel site Web PHP-MySQL ou même PHP.

Deuxièmement, sans rapport avec la question originale; Le noyau Linux devrait également être renforcé. Vous pouvez voir mon essence - https://gist.github.com/AbhishekGhosh/9407137

Normalement, PHP ne s'ouvre pas dans le navigateur comme un fichier texte, mais en affichant le chemin , nom et donne probablement l'indication que l'administrateur du serveur n'est pas très expérimenté et le rend plus vulnérable.

N'essayez pas de contrôler depuis le niveau .htaccess , gardez .htaccess aussi léger que possible. C'est en fait dans le répertoire public ...

Tant que vos points sont valides, aucun d'entre eux ne répond à la question qui a été posée. Le son ressemble plus à des commentaires aux réponses des autres.
Oui, je suis d'accord avec vous - "aucun d'entre eux ne répond à la question qui a été posée". Peut-être que c'était mieux comme commentaire à trysis. Merci aussi pour la modification.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...