Question:
Stratégie de sécurité Robots.txt?
neil
2012-01-31 09:44:42 UTC
view on stackexchange narkive permalink

Existe-t-il un moyen de mettre en place une politique autoriser tout sur votre domaine de premier niveau et que tous les sous-domaines interdisent tout? Je préférerais que mes serveurs d'applications publics ne soient pas indexés, mais d'après ce que je peux dire, aucun robot n'interroge même le fichier robots.txt lorsqu'il passe de notre domaine de premier niveau à un sous-domaine via un lien.

J'ai toujours eu envie de cartographier tous les endroits interdits pour les robots.txt, c'est donner une feuille de route à quiconque veut savoir où se trouvent les bonnes choses.

Quel type de stratégie de sécurité Robots.txt serait le mieux adapté à un environnement d'application Web?

il n'y a pas de stratégies de sécurité _robots.txt_, le fichier robots.txt n'a rien à voir avec la sécurité.
Cinq réponses:
Andy Smith
2012-01-31 15:41:45 UTC
view on stackexchange narkive permalink

Vous avez tort de supposer que le fichier robots.txt sur les sous-domaines est ignoré. La plupart des moteurs de recherche saisiront et obéiront au fichier robots.txt pour des sous-domaines individuels.

Si vous le souhaitez, vous pouvez demander aux araignées de ne pas indexer les éléments de votre site Web sans les répertorier dans le fichier robots.txt, soit:

  1. Ajout de <meta name = "robots" content = "noindex" / > au HTML des pages Web
  2. Ajout de X- Robots-Tag: noindex à vos en-têtes HTTP

Plus de détails disponibles ici

Cependant, malgré cela, vous ne devriez pas compter sur robots.txt pour la sécurité. Ce vers quoi vous vous penchez ici, c'est la sécurité par l'obscurité, qui est largement considérée comme une mauvaise idée.

Mauvaise idée en effet, mais cela peut être utilisé pour ajouter une couche de sécurité: l'algorithme / méthode utilisé serait rare et peut-être plus difficile à deviner qu'un mot de passe (comme changer les protocoles, en particulier ceux chiffrés, pensez-y comme si vous utilisiez un sel sur algorithmes de hachage).
tdammers
2012-01-31 18:32:42 UTC
view on stackexchange narkive permalink

En termes de sécurité, l'utilisation du fichier robots.txt a deux règles.

  1. N'essayez pas de mettre en œuvre une sécurité via le fichier robots.txt . Le fichier robots n'est rien de plus qu'une gentille suggestion, et bien que la plupart des robots des moteurs de recherche le respectent, les robots malveillants rigolent bien et continuent leurs activités. S'il est lié à, il peut être trouvé.
  2. N'exposez pas d'informations intéressantes via le fichier robots.txt . Plus précisément, si vous comptez sur l'URL pour contrôler l'accès à certaines ressources (qui est une énorme cloche d'alarme en soi), l'ajouter à robots.txt ne fera qu'aggraver le problème: un attaquant qui scanne robots.txt verra maintenant le secret URL que vous essayiez de cacher et concentrez vos efforts sur cette partie de votre site (vous ne voulez pas qu'elle soit indexée, et elle s'appelle «sekrit-admin-part-do-not-tell-any», donc c'est probablement intéressant).

Donc, par tous les moyens, utilisez le fichier robots.txt pour indiquer aux moteurs de recherche quelles parties de votre site vous voulez qu'ils indexent et quand les revoir, mais ne l'utilisez jamais pour des raisons de sécurité. Si vous avez des choses à cacher, utilisez une protection réelle (et si vous ne voulez pas que quelque chose apparaisse dans les résultats des moteurs de recherche, il est probable que vous devriez quand même le protéger par mot de passe).

Kenny Rasschaert
2012-01-31 12:51:38 UTC
view on stackexchange narkive permalink

Vous ne devriez jamais compter sur le fichier robots.txt pour vous offrir quelque discrétion ou sécurité que ce soit.

Bien sûr, les gros moteurs le respecteront, mais n'importe qui peut écrire un robot et trouver "les bonnes choses" , comme vous l'avez appelé.

S'il y a une ressource sur votre serveur Web à laquelle vous ne voulez pas que tout le monde puisse accéder, vous devez restreindre les autorisations en utilisant .htaccess ou un mécanisme similaire, selon le serveur.

Les règles htaccess et mod_security sont déjà déployées. Il ne s'agit pas tant de battre ceux qui ont les moyens d'explorer, mais plutôt de simplement régler les bots google / yandex / bing / etc pour éviter d'ajouter quelque chose à un google dork facile, et ainsi de le faire balayer mes affaires également.
Andreas Arnold
2012-01-31 13:50:46 UTC
view on stackexchange narkive permalink

Comme Kenny l'a dit, ne comptez pas sur le fichier robots.txt pour la sécurité. Si vous ne souhaitez pas qu'une page soit indexée, vous avez trois options ( si le robot d'exploration suit les consignes, ce que certains ne le feront pas):

  1. ajouter un rel = nofollow, noindex pour lier des balises qu'un robot d'exploration ne doit pas suivre ou indexer.
  2. Ajoutez un fichier robots.txt à chaque domaine et définissez le fichier robots.txt sur les sous-domaines sur deny /
  3. Ajoutez la balise d'en-tête <meta name = "robots" content = "noindex, nofollow" / > à chaque page que les robots d'exploration ne devraient pas ' t index.
  4. (facultatif) Il existe également un en-tête HTTP X-Robots-Tag: noindex, nofollow qui fait la même chose que la balise d'en-tête.
  5. ol>

    Il y aura des robots d'exploration qui l'ignoreront, mais les gros devraient suivre ces règles et ne pas indexer ces pages.

webgnomes
2012-02-05 14:11:40 UTC
view on stackexchange narkive permalink

Comme tout le monde l'a mentionné, votre fichier robots.txt ne fournit pas de mécanisme de sécurité, et si vous voulez dire aux robots d'exploration de NE PAS indexer vos sous-domaines, vous pouvez utiliser des fichiers robots.txt individuels pour chaque sous-domaine. Voici à quoi ressemblerait l'un de ces fichiers robots.txt:

User-agent: *
Disallow: /

Pour plus d'informations sur robots.txt, voici un quelques ressources:



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