Vos "fichiers secrets" restent secrets aussi longtemps que leurs noms (avec chemin complet) restent secrets. Vous pouvez considérer le chemin comme une sorte de mot de passe. Notez que les chemins vont fuir vers divers endroits (proxy, logs du serveur Web, historique de votre navigateur ...). Si les fichiers sont importants et sensibles, vous devez simplement faire les choses correctement:

• Utilisez SSL pour télécharger et accéder à ces fichiers.
• Configurez un mot de passe d'accès pour le répertoire où les fichiers le sont.

De cette façon, vous êtes de retour aux eaux connues: vous avez un (partie de) site Web avec des données sensibles et protégé par un mot de passe. Rendez-le fort, et vous êtes prêt.

Dans le cas du sous-domaine: ce "sous-domaine" est annoncé au monde entier via le DNS. Il est possible de configurer les serveurs DNS de manière à ce que les tiers ne puissent pas facilement énumérer tous les sous-domaines d'un domaine, mais cela demande une certaine prudence. De plus, chaque fois que vous accédez à ce sous-domaine, votre machine utilisera des requêtes DNS (pour l'adresse IP correspondante); ces requêtes voyagent sans protection particulière et contiennent le nom de sous-domaine. Il s'agit donc d'une proie facile pour les écoutes passives (c'est-à-dire "les personnes connectées au même point d'accès WiFi que vous"). Il serait trop optimiste de croire au secret d’un sous-domaine.

Je vois quatre possibilités de fuite de chemin

1) bruteforce

2) malware sur votre hôte

3) accident =) vous pouvez partager ce chemin à quelqu'un ou oublié de supprimer, ou de lier ceci à partir d'un endroit par accident.

4) google chrome =) parce que Google utilise les informations de chrome (et probablement ff) pour alimenter le robot d'exploration

la même chose est à propos de DNS. Se fier au chemin est une mauvaise pratique.

Il existe une autre façon de divulguer des informations sur les pages Web "secrètes": lorsque la page appelle d'autres documents (pages Web, mais aussi javascript ou feuilles de style), l'en-tête du référent pointe vers cette page.

A Le scénario courant consiste à charger le populaire JQuery.js directement à partir de code.google.com, en laissant une page Web dans la recherche Google.

Les statistiques d'accès sont également exposées à Google dans ce cas.

Notez que ce type de fuite ne peut pas être contourné en exigeant https. La protection par mot de passe est utile dans la mesure où seuls le nom et le chemin de la page secrète, mais pas son contenu, sont exposés.

Gardez tout local.

Première question concernant les pages d'administration: si vous supprimez les pages Web après avoir fini de les utiliser, personne ne pourra les trouver. Cependant, si vous les laissez sur le serveur, ils peuvent être trouvés. Il existe des outils d'analyse de site Web qui peuvent analyser votre site Web à l'aide d'un dictionnaire pour trouver des ressources «cachées».

Afin de mieux protéger ces fichiers, j'ajouterais des contrôles d'accès aux répertoires. Si vous utilisez Apache, consultez .htaccess. Je configurerais également le fichier robots.txt pour demander aux moteurs de recherche de ne pas explorer les zones que vous souhaitez garder cachées.

Deuxième question concernant le sous-domaine: Il est très facile de découvrir des sous-domaines pour les sites Web . Les attaquants peuvent essayer de faire en sorte que vos serveurs DNS renoncent à ces informations, ou ils peuvent simplement utiliser Google pour découvrir ces domaines. Par exemple, supposons que vous souhaitiez trouver tous les sous-domaines de yahoo.com, essayez la recherche Google "site: yahoo.com -www". Tous les sous-domaines que Google a explorés sont répertoriés dans les résultats de recherche. Un script Python rapide pour les analyser et le tour est joué!