Question:
Un site Web publié dans un annuaire obscur est-il comparable à celui d'être placé derrière une connexion?
CodeMoose
2015-05-13 01:14:09 UTC
view on stackexchange narkive permalink

Disons que je crée un microsite pour un client contenant des informations commerciales confidentielles. Nous devons le placer dans un emplacement auquel le client peut accéder, afin qu'il puisse approuver le lancement.

Si nous plaçons ce microsite derrière une connexion, nous avons une 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 des raisons d'argumentation, "non divulgué et non indexé" signifie qu'il ne sera pas manuellement ou automatiquement lié à / de n'importe où, ni 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 qu'il s'agit simplement de sécurité par obscurité, et est beaucoup moins sécurisé en raison du possibilité que quelqu'un trébuche dessus. Mais, après y avoir réfléchi, je ne suis pas si sûr. Voici ce que je comprends:

  • Même en utilisant une chaîne de deux mots faible par 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 contre la force brute, de sorte qu'un attaquant obtiendrait de manière optimiste 20 tentatives de deviner. Les devinettes d'URL devraient être interceptées par la protection DoS ou anti-spam du serveur, et peuvent permettre à 200 estimations de produire 404 si vous prévoyez une attaque - toujours pas statistiquement significative pour des milliards d'options.
  • La page de connexion est lié à partir d'un site Web - c'est un mur visible sur lequel un attaquant peut se battre. C'est la preuve que quelque chose vaut la peine d'être attaqué. Cependant, deviner l'URL est aveugle. Cela nécessite d'être sur le bon domaine (et sous-domaine), et de fonctionner avec la foi que, même après des dizaines de milliers de suppositions incorrectes, vous allez toujours changer quelque chose.
  • L'URL a une susceptibilité supplémentaire d'être indexée / repérée en externe. Cependant, la plupart des araignées respectables ne «devinent» pas les sites, elles suivent simplement les liens. Une araignée malveillante "devinant" serait attrapé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 rend les choses sécurisées, même si elles semblent comparables sur la base des points ci-dessus. L'option d'URL s'oppose comme elle devrait être beaucoup moins sécurisée, cependant. Qu'est-ce que je ne prends pas en compte?


MODIFIER: Beaucoup de problèmes d'erreur humaine valides apparaissent. Cette question a été inspirée par un client qui implémente un degré de sécurité à l'épreuve des humains - connexion VPN via la télécommande, les gradateurs d'écran, les délais d'attente de 5 minutes, la panne des réseaux sociaux, etc. Pour cette question, veuillez supposer qu'aucun accès au réseau public et aucune violation accidentelle comme regarder l'épaule ou "oups! J'ai posté le lien vers Twitter!". Je recherche une réponse plus systématique, ou au moins une réponse plus satisfaisante que "les humains foutent la merde".


MODIFIER 2: Merci d'avoir signalé le doublon possible. IMHO, 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 en base64). Cette question aborde plus spécifiquement le concept de secret vs d'obscurité, et l'applique à la raison pour laquelle 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 explique ma question particulière aussi profondément ou complètement que la bonne réponse de @ SteveDL ci-dessous.

Ce n'est pas une réponse complète, je vais donc la mettre en commentaire: lorsque l'URL est le secret, souvent les gens ne la traiteront pas aussi soigneusement que certaines autres informations comme un utilisateur / un mot de passe. Bien sûr, une URL suffisamment complexe est utilisée tout le temps pour protéger les données confidentielles (les sites de partage de fichiers dans le cloud font tout à l'heure) mais cela ne fait pas la même chose qu'un utilisateur / transmet généralement (mais pas toujours) regarder avec un peu plus de révérence. Si l'échelle de temps est courte (c'est-à-dire qu'elle n'est active que pendant quelques jours, puis effacée), vous n'augmentez pas vraiment le risque en procédant de cette façon.
@JeffMeden Pour les sites Web de partage dans le cloud, les éléments qui doivent réellement être sécurisés ne sont pas seulement accessibles avec une URL; vous devez également être connecté.
Les secrets tels que les mots de passe sont gardés secrets * de par leur conception *. Ils sont utilisés, transférés et stockés en cas de besoin, puis lâchés. Les URL ne sont pas considérées comme des secrets et en tant que telles ne sont pas traitées dans le but de minimiser leur durée de vie par tous les acteurs de l'écosystème Internet. C'est ce qui vous manque.
@SteveDL Je pense que vous avez raison - même en ignorant les expositions accidentelles / accidentelles, c'est la perception du lien par rapport au mot de passe qui cause le problème. Si vous le postez comme réponse, je l'accepterai!
Idem @JeffMeden
Terminé. Notez que toutes les réponses sont également bonnes à ce stade. De plus, ne supposez pas que les personnes qui raisonnent exclusivement en termes de sécurité ont couvert l'aspect «erreur humaine». Cela nécessite l'embauche de designers d'interaction, d'ethnographes et autres :-)
L'ajout d'un mot de passe peut être très simple lorsque vous utilisez simplement une connexion HTTP au lieu d'un formulaire HTML sophistiqué. Sur Apache, par exemple, vous pouvez le faire en plaçant un fichier .htaccess avec le nom d'utilisateur et le mot de passe dans le même répertoire sur votre serveur Web - c'est moche mais rapide à faire et fait le travail.
Notez que publier l'URL à quelqu'un dans un chat Facebook * privé * (et quelques autres services) déclenchera un accès à cette URL.
Je n'ai vu personne d'autre mentionner cela, mais vous pouvez atténuer le problème de l'exposition de l'URI pendant la transmission en plaçant le "mot de passe" derrière un hachurage (#) et en faisant en sorte que du javascript le déplace dans le corps d'une requête XHR. Les navigateurs n'enverront pas le "Hash URI" (à ne pas confondre avec un hachage cryptographique). Cependant, il n'est pas destiné à contenir des secrets, donc tous les autres problèmes de journalisation de l'historique du navigateur et autres s'appliquent toujours.
@ZevChonoles alors que les deux questions soulèvent des préoccupations similaires concernant la sécurité URI, à mon humble avis, je pense que chacune 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 en base64). Cette question aborde plus spécifiquement le concept de secret vs d'obscurité, et l'applique à la raison pour laquelle une connexion est meilleure qu'un URI indépendant du type de données en question.
Regardez aussi cette question et ses réponses (pensez spécialement à votre client qui teste le site avec Google Chrome (autsch!): Http://security.stackexchange.com/questions/63124/how-can-outsiders-discover-the-pages -qui-sont-hébergés-sur-mon-serveur / 63167 # 63167
Six réponses:
Steve Dodier-Lazaro
2015-05-13 04:03:58 UTC
view on stackexchange narkive permalink

Je vais développer un point à un niveau légèrement plus abstrait sur les raisons pour lesquelles les espaces publics authentifiés sont préférables aux espaces cachés non protégés. Les autres réponses sont toutes parfaitement bonnes et répertorient plusieurs attaques qu'il faut savoir mieux éviter.

Tout le monde avec une formation formelle devrait avoir entendu à un moment donné le principe de sécurité Open Design. Il stipule que les systèmes ne doivent pas se fier aux détails de leur conception et de leur mise en œuvre étant secrets pour leur fonctionnement. Qu'est-ce que cela nous dit sur les mots de passe secrets et les URL secrètes?

Les mots de passe sont des secrets d'authentification. Ils sont connus par une entité contestée qui les fournit à une entité exigeante 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:

  1. L'utilisateur doit être piégé ou forcé à révéler le mot de passe
  2. Le serveur doit être piraté afin qu'il révèle une version hachée du mot de passe
  3. 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 des exigences de stockage et canaux de transmission, et donc avec des canaux d'attaque différents (principe de séparation des privilèges).

Nous pouvons déjà conclure que les URL obscures ne peuvent pas être meilleures 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 , en revanche, sont beaucoup plus souvent manipulées. Cela est en grande partie dû au fait que plusieurs entités automatisées et manuelles de l'écosystème Internet traitent régulièrement les URL. Le secret de l'URL repose sur le fait qu'elle soit cachée à la vue , ce qui signifie qu'elle doit être traitée par tous ces tiers comme s'il s'agissait d'une marchandise publique déjà connue, l'exposant aux yeux de tout. 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 confidentiels. protected
  • Il n'est pas nécessaire que les espaces de stockage soient protégés en matière de confidentialité ou d'intégrité, ni de surveillance des fuites de données
  • La durée de vie des URL copiées est en grande partie hors du contrôle du client d'origine et les principaux du serveur

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 devriez cacher quelque chose à la vue de tous que s'il est impossible pour des tiers de comprendre cela. Dans le cas des URL, l'URL ne peut être fonctionnelle que dans l'ensemble de l'écosystème Internet (y compris votre navigateur du 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 permettant à vos adversaires de l'utiliser pour s'adresser à votre serveur.

En conclusion, respectez le principe de conception ouverte.

J'aimerais pouvoir +2 ceci - exactement ce que je cherchais. J'examinais le problème de trop près au microscope et je n'ai pas tenu compte des implications dans l'écosystème en général. Merci pour la bonne réponse!
k1DBLITZ
2015-05-13 02:43:00 UTC
view on stackexchange narkive permalink

Puisque nous parlons théoriquement, voici plusieurs raisons pour lesquelles une URL aléatoire seule ne suffit pas 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 sûr de certains de vos puces.

Êtes-vous en train de dire que ce serveur / site Web potentiel / platform a en effet une protection contre le fuzzing de répertoire, ou est-ce hypothétique?

Même ainsi, il ne protège pas contre les éléments que j'ai mentionnés ci-dessus.

Enfin, merci: les URL sont collectées par votre gouvernement pour votre propre bien, ou quelque chose comme ça.
De plus, si un ordinateur portable a ouvert la page, il est beaucoup plus facile de tenter accidentellement de recharger l'URL sur un réseau non sécurisé que de POST accidentellement le mot de passe sur un réseau non sécurisé.
+1 pour être concis et informatif - merci pour la réponse!
@Steve DL Pas seulement le gouvernement. Si vous naviguez à partir du réseau de votre employeur, d'un wifi starbuck gratuit, de votre FAI DSL ou de votre connexion de données de téléphone mobile, ils ont accès à votre historique de navigation. Votre employeur pourrait être intéressé de voir si vous êtes entré dans Facebook. Au moins si vous n'utilisez pas TOR ou un logiciel similaire
@SteveDL ... et même par des organisations au-dessus des gouvernements. Par exemple, un Internet Explorer configuré de manière innocente peut demander à Microsoft s'il est sûr de visiter cette URL, qu'ils testent en visitant cette URL. En d'autres termes, vous remarquerez * vraiment * les accès surprises involontaires aux URL obscures dans vos journaux.
Gilles 'SO- stop being evil'
2015-05-13 03:00:40 UTC
view on stackexchange narkive permalink

Deviner l'URL, cependant, est aveugle. Cela nécessite d'ê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.

Les moteurs de recherche ne pas être respectables est une position défendable, mais cela ne change pas le fait qu'ils font plus que suivre des liens. En particulier, les moteurs de recherche peuvent énumérer les entrées DNS et le font, donc la simple existence d'un sous-domaine est un risque.

Beaucoup de choses se retrouvent sur Google même si les gens jurent qu'ils ne s'y sont jamais liés de nulle part et Google ne renvoie aucune page qui renvoie au site.

En plus du problème, les gens ne traitent généralement pas les URL comme confidentielles et que les URL apparaissent dans toutes sortes d'endroits tels que le serveur, les journaux du navigateur et du proxy. Les URL sont également visibles et utilisées par beaucoup plus d'extensions de navigateur que de mots de passe. Si le site "caché" a des liens sortants, l'URL est susceptible d'apparaître dans les en-têtes de Referer: .

Il y a aussi le risque qu'en raison d'une mauvaise configuration, un lien vers le site caché apparaît dans un endroit non caché, par exemple si le site caché est hébergé sur un site qui offre 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 à battre. C'est la preuve que quelque chose vaut la peine d'être attaqué.

Cela n'a pas de sens. Utilisez un logiciel décent et un mot de passe généré aléatoirement, et il n'y a pas de surface d'attaque à explorer. En revanche, un répertoire caché ne ressemble même pas à quelque chose qui vaut la peine d'être attaqué, il ressemble à quelque chose qui est ouvert au public.

Une URL secrète est particulièrement risquée, 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 quand même 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.

Même si vous soulevez de bons points, je ne pense pas que vous ayez abordé l'esprit de la question. Je suis d'accord sur la vulnérabilité DNS - c'est pourquoi cette question concerne des sous-répertoires, pas des sous-domaines. L'indexation accidentelle est sans objet, car l'une des hypothèses de la question est que le sous-répertoire est établi non divulgué et non indexé. Enfin, je suis respectueusement en désaccord avec le fait que le point de la page de connexion "n'a aucun sens". Quelle valeur y a-t-il à ce qu'un attaquant choisisse un domaine aléatoire et recherche un contenu éventuellement caché? Cela ne réussira presque jamais. Une page de connexion, même verrouillée, fournit des commentaires.
Bien que je comprenne les points que vous essayez de faire valoir, il peut être avantageux de faire un peu plus d'efforts pour comprendre la question réelle afin que vous puissiez y répondre avec précision. J'essaierai également d'apporter des modifications pour clarifier ce que je demande.
@CodeMoose Les commentaires qui disent simplement «mauvais mot de passe» ne sont pas utiles. L'indexation accidentelle n'est pas un point discutable, c'est un risque assez courant. Je suis raisonnablement convaincu d'avoir compris la question et j'ai abordé directement bon nombre de vos points.
Et pourtant, ce que je lis semble dire "voici pourquoi ce n'est pas une question réaliste à poser", et non "étant donné ces points, voici le facteur x que vous n'avez pas considéré". Encore une fois, j'apprécie votre contribution, vous savez très clairement de quoi vous parlez :) Je cherche simplement une réponse dans une autre voie, et j'essayais de donner une rétroaction à cet effet.
@CodeMoose J'ai vraiment du mal à comprendre votre commentaire. Ma réponse est à peu près seulement «voici les facteurs x, y, z que vous n'avez pas pris en compte», et je ne dis nulle part quelque chose comme «ce n'est pas une question réaliste». C'est une question réaliste et raisonnable, et la réponse est un non catégorique.
@CodeMoose Je pense que vous vous attendiez à un commentaire de haut niveau sur la conception de votre exigence de sécurité, mais vous avez posé la question en termes de mise en œuvre, d'où vous avez attiré des réponses au niveau de la mise en œuvre. Est-ce exact?
@SteveDL Cela pourrait être correct - je pensais avoir une solide compréhension de la question, mais il semble que ce soit plus nuancé que je ne le pensais. Merci de vous occuper de moi!
@Gilles merci également pour l'excellente réponse, a appris beaucoup de choses inattendues dans ce processus.
Mais que se passe-t-il si le mot de passe est en fait divulgué d'une manière conviviale pour les moteurs de recherche, comme un lien vers http: // username: password@example.com/secretpage.html?
@HagenvonEitzen Les gens utilisent-ils encore l'authentification HTTP de base de nos jours?
David Mulder
2015-05-14 03:10:21 UTC
view on stackexchange narkive permalink

Je suis d'accord avec les autres réponses selon lesquelles c'est une mauvaise idée, simplement parce que les gens (=> développeurs => applications qui enregistrent des informations) ne considèrent pas les URL comme privées et il existe donc de nombreuses façons différentes pour clé a pu être divulguée. 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 programme que vous proposez. Le seul problème vient du fait que le système que vous proposez utilise à mauvais escient les systèmes d'une manière pour laquelle ils n'étaient pas destinés.

Même en utilisant une chaîne de deux mots faible par 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 protection contre la force brute, de sorte qu'un attaquant obtiendrait 20 tentatives optimistes pour deviner. Les devinettes d'URL devraient être capturées par la protection DoS ou anti-spam du serveur, et peuvent permettre de générer 200 estimations 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 sur lequel un attaquant peut se battre. C'est la preuve que quelque chose vaut la peine d'être attaqué. Cependant, deviner l'URL est aveugle. Cela nécessite d'être sur le bon domaine (et sous-domaine), et de fonctionner avec la foi que, même après des dizaines de milliers de suppositions incorrectes, vous allez toujours changer quelque chose.

Tout à fait 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 lequel s'appuyer? Définitivement pas. Est-ce quelque chose qui pourrait arrêter certains attaquants discrets? Certainement.

Quoi qu'il en soit, cela ne fournit qu'un avantage limité en soi par rapport à un gros compromis comme décrit dans le premier paragraphe.

L'URL a une susceptibilité supplémentaire d'être indexé / spotted extérieurement. Cependant, la plupart des araignées respectables ne «devinent» pas les sites, elles suivent simplement les liens. Une araignée malveillante "devinant" serait interceptée par la même protection DoS / spam que le point 2.

Le seul problème avec les araignées est qu'elles pourraient trouver un cache aléatoire quelque part où l'URL était liée et indexez-les d'une manière qui est plus facile à trouver pour les autres. La conjecture aléatoire n'est en effet pas un problème.

Atsby
2015-05-13 06:11:03 UTC
view on stackexchange narkive permalink

J'ai personnellement utilisé HTTPS-with-unguessable-URL comme protocole pour livrer des fichiers en toute sécurité. Avec l'historique du navigateur désactivé du côté de la réception, et si l'URL est communiquée de manière aussi sécurisée qu'un mot de passe, c'est à peu près aussi sécurisé qu'une page de connexion HTTPS. Ce qui est beaucoup moins sécurisé que, par exemple, GnuPG.

L'URL elle-même n'est cependant pas chiffrée. Tout nœud du chemin peut voir l'URL, puis récupérer ce fichier.
@schroeder L'utilisation de HTTP ** S ** empêche cela (oui, les URL sont envoyées via SSL / TLS dans HTTP ** S **). Bien sûr, vous avez besoin d'un vrai certificat, par opposition à l'auto-signature, pour éviter les attaques MITM.
C'est vrai, mais avec des exceptions notables: les proxys côté client, les journaux d'accès du serveur et les équilibreurs de charge / déchargeurs SSL du côté du serveur.
@schroeder Eh bien, techniquement, un mot de passe POST passe par tout cela également dans ces scénarios. La seule chose différente serait la journalisation.
702cs
2015-05-13 03:52:44 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont dit, si vous prévoyez de laisser cet annuaire et ce site Web pendant un jour ou deux avec des informations et des données confidentielles et que vous êtes dans un manque de temps sérieux, ce serait acceptable mais pas la "meilleure pratique". En d'autres termes, ce n'est pas recommandé, mais si vous sentez que vous devez prendre le risque.

Le principal problème avec ce concept est que se passe-t-il si le client a un rootkit ou un enregistreur de frappe sur sa machine? Et si une autre partie obtient le lien? Ce que je dis, c'est que toute personne qui obtient ce lien pourra accéder à ces données confidentielles. Je mettrais une connexion rapide sur la page pour n'autoriser l'accès qu'aux clients auxquels les données sont destinées.

Si le périphérique d'un client est compromis, vous avez besoin de facteurs d'authentification qui ne nécessitent * pas * de faire confiance à la machine cliente pour conserver l'entrée du client pour elle-même. Un mot de passe serait également capturé par un keylogger.
702cs, comme @SteveDL l'a déjà commenté, votre solution ne protège pas contre les enregistreurs. De plus, ce type de comportement à risque doit être évité et non approuvé car son risque est élevé et vous ne pouvez pas prédire le résultat. Continuez et continuez à répondre (nous obtenons tous de `` mauvaises '' réponses avant d'apprendre ce que sont les bonnes réponses;))


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