Un site Web publié dans un répertoire obscur est-il relativement sûr d'être placé derrière une connexion?
Supposons que je crée un microsite pour un client qui contient des informations commerciales confidentielles. Nous devons le placer dans un endroit auquel le client peut accéder, afin qu'il approuve le lancement.
Si nous plaçons ce microsite derrière une connexion, nous avons la garantie que personne ne peut tomber sur le contenu et le compromettre. Mais, que se passe-t-il si nous le publions dans un répertoire non divulgué et non indexé avec un nom de la même "force" que le mot de passe susmentionné? Pour les besoins de l'argument, "non divulgué et non indexé" signifie qu'il ne sera pas lié manuellement ou automatiquement à/de n'importe où, ou indexé par une recherche de site Web sur le même domaine. Il ne sera pas non plus placé dans son propre sous-domaine, donc l'exploration DNS n'est pas un problème.
Mon instinct initial dit que c'est simplement la sécurité par l'obscurité, et est beaucoup moins sécurisé en raison de la possibilité que quelqu'un trébuche dessus. Mais, après y avoir réfléchi, je n'en suis pas si sûr. Voici ma compréhension:
- Même en utilisant une chaîne de deux mots faible en dictionnaire pour le mot de passe et l'URL, il existe encore des milliards d'options devinables. Le placer dans l'URL ne réduit pas comme par magie cette liste.
- Les pages de connexion peuvent avoir une protection par force brute, donc un attaquant obtiendrait de façon optimiste 20 tentatives de deviner. La supposition d'URL devrait être détectée par le DoS ou la protection anti-spam du serveur, et pourrait permettre 200 suppositions produisant 404 si vous prévoyez une attaque - toujours pas statistiquement significative pour des milliards d'options.
- La page de connexion est liée à partir d'un site Web - c'est un mur visible pour un attaquant. C'est la preuve que quelque chose existe qui mérite d'être attaqué. Mais deviner l'URL est aveugle. Cela nécessite d'être sur le bon domaine (et sous-domaine) et d'opérer sur la foi que, même après des dizaines de milliers de suppositions incorrectes, vous allez toujours tourner quelque chose.
- L'URL a une sensibilité supplémentaire d'être indexée/araignée en externe. Cependant, la plupart des araignées respectables ne "devinent" pas les sites, elles suivent simplement les liens. Une araignée "devinante" malveillante serait capturée par la même protection DoS/spam que le point 2.
D'après ce que je peux dire, la seule différence significative entre les deux est la tranquillité d'esprit imaginée. La possibilité que l'URL puisse être trébuchée rend les gens nerveux et la connexion sécurise les choses, même si elles semblent comparables sur la base des points ci-dessus. L'option URL reste se sent comme si elle devrait être beaucoup moins sécurisée, cependant. Qu'est-ce que je ne pense pas?
EDIT: Beaucoup de problèmes d'erreur humaine valides apparaissent. Cette question a été inspirée par un client qui met en œuvre un certain degré de sécurité à l'épreuve des humains - connexion VPN via un porte-clés, des gradateurs d'écran, des délais de veille de 5 minutes, une panne de réseau social, etc. comme regarder les épaules ou "oups! J'ai posté le lien sur Twitter!". Je cherche une réponse plus systématique, ou au moins une plus satisfaisante que "les humains bousillent".
EDIT 2: Merci d'avoir signalé le doublon possible . À mon humble avis, je pense que chacun a une valeur en tant que question individuelle. Cette question porte spécifiquement sur la sécurité des images et explore d'autres méthodes de sécurisation et de codage de ces données (par exemple, le codage base64). Cette question aborde plus spécifiquement le concept de secret par rapport à l'obscurité et l'applique aux raisons pour lesquelles une connexion est meilleure qu'un URI indépendant du type de données en question. De plus, je ne pense pas que la réponse acceptée ici explique ma question particulière aussi profondément ou complètement que l'excellente réponse de @ SteveDL ci-dessous.
Je vais m'étendre sur un point à un niveau légèrement plus abstrait sur la raison pour laquelle les espaces publics authentifiés sont préférables aux espaces non protégés cachés. Les autres réponses sont toutes parfaitement bonnes et énumèrent plusieurs attaques qu'il faut mieux éviter.
Toute personne ayant une formation officielle aurait dû entendre à un moment donné le principe de sécurité Open Design . Il stipule que les systèmes ne doivent pas dépendre de détails de leur conception et de leur mise en œuvre qui sont secrets pour leur fonctionnement. Qu'est-ce que cela nous apprend sur les mots de passe secrets et les URL secrètes?
Les mots de passe sont des secrets d'authentification. Ils sont connus d'une entité en difficulté qui les fournit à une entité en difficulté afin de s'authentifier. Les deux parties ont besoin d'une forme de stockage et d'un canal de communication. Voler le mot de passe nécessite de compromettre l'un des trois. Typiquement:
- L'utilisateur doit être piégé ou forcé à révéler le mot de passe
- Le serveur doit être piraté afin qu'il révèle une version hachée du mot de passe
- La confidentialité du canal entre l'utilisateur et le serveur doit être compromise
Notez qu'il existe de nombreuses façons de renforcer l'authentification, en commençant par ajouter un facteur d'authentification supplémentaire avec différentes exigences de stockage et canaux de transmission, et donc avec différents canaux d'attaque (principe de séparation des privilèges).
Nous pouvons déjà conclure que les URL obscures ne peuvent pas être mieux que les mots de passe car dans tous les vecteurs d'attaque sur les mots de passe, l'URL est soit connue (2 et 3), soit accessible (1).
Les URL obscures d'autre part sont manipulées beaucoup plus fréquemment. Cela est en grande partie dû au fait que plusieurs entités automatisées et manuelles dans l'écosystème Internet traitent régulièrement les URL. Le secret de l'URL repose sur le fait qu'il est caché à la vue, ce qui signifie qu'il doit être traité par tous ces tiers comme s'il s'agissait d'un produit public, déjà connu, l'exposant à les yeux de tous. Cela conduit à plusieurs problèmes:
- Les vecteurs par lesquels ces URL obscures peuvent être stockées, transmises et copiées sont beaucoup plus nombreux
- Les canaux de transmission ne sont pas tenus d'être protégés par la confidentialité
- Il n'est pas nécessaire que les espaces de stockage soient protégés par confidentialité ou intégrité, ni surveillés pour les fuites de données
- La durée de vie des URL copiées est dans une large mesure hors du contrôle des principaux clients et serveurs d'origine
En bref, toutes les possibilités de contrôle sont immédiatement perdues lorsque vous avez besoin qu'un secret soit traité ouvertement. Vous ne devez cacher quelque chose à la vue que s'il est impossible pour des tiers de donner un sens à cette chose. Dans le cas des URL, l'URL peut être fonctionnel dans tout l'écosystème Internet (y compris le navigateur de votre client, une variété de serveurs DNS et votre propre serveur Web) si cela peut être compris, il doit donc être conservé dans un format où vos adversaires peuvent l'utiliser pour répondre à vos serveur.
En conclusion, respectez le principe de conception ouverte.
Puisque nous parlons théoriquement, voici plusieurs raisons pour lesquelles une URL aléatoire seule n'est pas suffisante pour protéger les données confidentielles:
- Les URL peuvent être mises en signet.
- Les URL sont enregistrées dans l'historique du navigateur (kiosque public).
- Les URL sont affichées dans la barre d'adresse (surfeurs d'épaule).
- Les URL sont enregistrées (pensez à un proxy tiers).
- Les URL peuvent être divulguées via les en-têtes de référent
Je ne suis pas clair sur certains de vos points de balle.
Êtes-vous en train de dire que ce serveur Web/site Web/plate-forme potentiel a en effet une protection de l'exploration de répertoire, ou est-ce hypothétique?
Néanmoins, il ne protège pas contre les éléments que j'ai mentionnés ci-dessus.
Mais deviner l'URL est aveugle. Il faut être sur le bon domaine (et sous-domaine)
Cependant, la plupart des araignées respectables ne "devinent" pas les sites, elles suivent simplement les liens "
Considérer que les principaux moteurs de recherche ne sont pas respectables est une position défendable, mais cela ne change pas le fait qu'ils font plus que suivre les liens. En particulier, les moteurs de recherche peuvent énumérer les entrées DNS et l'énumèrent, de sorte que la simple existence d'un sous-domaine constitue un risque.
Beaucoup de choses se retrouvent sur Google, même si les gens jurent qu'ils ne s'y sont jamais connectés de quelque part et que Google ne renvoie aucune page qui renvoie vers le site.
C'est en plus du problème que les gens ne traitent généralement pas les URL comme confidentiels, et que les URL apparaissent dans toutes sortes d'endroits tels que les journaux de serveur, de navigateur et de proxy. Les URL sont également visibles et utilisées par beaucoup plus d'extensions de navigateur que de mots de passe. Si le site "masqué" contient des liens sortants, l'URL est susceptible d'apparaître dans Referer: en-têtes.
Il existe également le risque qu'en raison d'une mauvaise configuration, un lien vers le site masqué apparaisse dans un emplacement non masqué, par exemple si le site masqué est hébergé sur un site proposant une fonction de recherche locale.
La page de connexion est liée à partir d'un site Web - c'est un mur visible pour un attaquant. C'est la preuve que quelque chose existe qui mérite d'être attaqué.
Cela n'a aucun sens. Utilisez un logiciel décent et un mot de passe généré de manière aléatoire, et il n'y a aucune surface d'attaque qui mérite d'être poursuivie. En revanche, un répertoire caché ne ressemble même pas à quelque chose qui mérite d'être attaqué, il ressemble à quelque chose qui est ouvert au public.
Une URL secrète est particulièrement sujette aux risques car si l'URL est divulguée accidentellement et qu'un moteur de recherche la découvre, tout le contenu du site sera exposé via ce moteur de recherche. Un mot de passe n'échoue pas de manière aussi catastrophique: si le mot de passe est divulgué, il faut toujours une action volontaire pour que quelqu'un commence à télécharger les données, il ne démarre pas automatiquement une machine qui le publiera pour que tout le monde puisse le voir.
Je suis d'accord avec les autres réponses que c'est une mauvaise idée, tout simplement parce que les gens (=> développeurs => les applications qui enregistrent les informations) ne considèrent pas les URL comme privées et donc il y a beaucoup de façons différentes de clé pourrait être divulgué. Ce que vous avez cependant correctement reconnu, c'est que les mots de passe sont essentiellement une forme de sécurité par l'obscurité. Et que conceptuellement il n'y a rien de mal avec le schéma que vous proposez. Le seul problème est dû au fait que le schéma que vous proposez utilise les systèmes de manière inappropriée.
Même en utilisant une chaîne de deux mots faible en dictionnaire pour le mot de passe et l'URL, il existe encore des milliards d'options devinables. Le placer dans l'URL ne réduit pas comme par magie cette liste.
C'est vrai, mais cela ne le rend pas plus sûr non plus.
Les pages de connexion peuvent avoir une protection par force brute, donc un attaquant obtiendrait de façon optimiste 20 tentatives de deviner. La supposition d'URL devrait être détectée par le DoS ou la protection anti-spam du serveur, et pourrait permettre 200 suppositions produisant 404 si vous prévoyez une attaque - toujours pas statistiquement significative pour des milliards d'options.
Si vous prévoyez une attaque, vous la limiterez probablement également aux meilleures pratiques de protection par force brute pour votre type d'application. Donc, en effet, ce n'est pas pire si c'est bien fait, mais ce n'est certainement pas mieux et sera probablement pire car vous devrez faire beaucoup plus de travail personnalisé.
La page de connexion est liée à partir d'un site Web - c'est un mur visible pour un attaquant. C'est la preuve que quelque chose existe qui mérite d'être attaqué. Mais deviner l'URL est aveugle. Cela nécessite d'être sur le bon domaine (et sous-domaine) et d'opérer sur la foi que, même après des dizaines de milliers de suppositions incorrectes, vous allez toujours tourner quelque chose.
Absolument vrai, et pour cette raison, j'ai vu certaines entreprises cacher leurs pages de connexion intranet sur des URL légèrement imprévisibles. Est-ce quelque chose sur quoi compter? Définitivement pas. Est-ce quelque chose qui pourrait arrêter certains attaquants discrets? Absolument.
Quoi qu'il en soit, cela ne fournit cependant que des avantages limités en soi par rapport à un important compromis tel que décrit dans le premier paragraphe.
L'URL a une sensibilité supplémentaire d'être indexée/araignée en externe. Cependant, la plupart des araignées respectables ne "devinent" pas les sites, elles suivent simplement les liens. Une araignée "devinante" malveillante serait capturée par la même protection DoS/spam que le point 2.
Le seul problème avec les araignées est qu'elles peuvent trouver un cache aléatoire quelque part où l'URL a été liée et l'indexer d'une manière plus facile à trouver pour les autres. Deviner au hasard n'est en effet pas un problème.