Les requêtes GET secrètes peuvent-elles être forcées brutalement?
Dis, j'ai sur mon serveur une page ou un dossier que je veux garder secret.
example.com/fdsafdsafdsfdsfdsafdrewrew.html
ou
example.com/fdsafdsafdsfdsfdsafdrewrewaa34532543432/admin/index.html
Si la partie secrète du chemin est assez longue, puis-je supposer qu'il est sûr d'avoir une telle page ou zone secrète, et ce sera difficile à deviner ou à la forcer brutalement?
Quels sont les problèmes avec cette approche en général?
Notez que je ne demande pas comment procéder correctement, mais quels pourraient être les problèmes avec cette approche, le cas échéant.
Vous demandez essentiellement s'il est sûr de passer des paramètres secrets dans une demande GET. Ceci est en fait classé comme vulnérabilité . Il n'est pas possible de forcer brutalement une chaîne pseudo-aléatoire suffisamment longue, en supposant que le serveur renvoie simplement une réponse statique 404 chaque fois qu'un chemin non valide est spécifié, mais il existe de nombreux autres problèmes de sécurité dans la pratique qui en font une technique dangereuse:
Le logiciel de journalisation enregistre souvent les requêtes GET en texte clair, mais pas en POST.
L'utilisation de GET rend CSRF trivial* lors du traitement du contenu actif.
Les en-têtes de référents peuvent divulguer des valeurs secrètes à d'autres sites Web.
L'historique du navigateur conservera les secrets transmis dans les requêtes GET.
Votre deuxième exemple a /admin/ dedans. Cela implique pour moi que la seule connaissance de ce chemin serait suffisante pour s'authentifier auprès du serveur dans un contexte administrateur. C'est très peu sûr et ne devrait pas être fait plus que /?password=hunter2, une sécurité Web majeure faux pas .
Au lieu de cela, les secrets doivent être envoyés dans une demande POST. Si cela n'est pas possible ou si votre modèle de menace est exclusivement pour empêcher la force brute de l'URL (par exemple, les liens de réinitialisation de mot de passe qui sont rapidement invalidés après leur utilisation), alors cela devrait être sûr si cela est fait avec soin. Je ne suis au courant d'aucune attaque de canal latéral qui fournirait une méthode pour obtenir la chaîne plus rapidement que la force brute.
* Éviter les requêtes GET paramétrées n'empêche pas les attaques CSRF, ce qui est une idée fausse commune car il existe différentes façons d'abuser de la même manière POST (faux formulaires, etc.), mais en passant les secrets de GET rendent la CSRF plus facile.
Il s'agit d'une approche courante pour partager des objets publics limités à ceux qui connaissent l'URL. Un exemple est Google Docs:
La deuxième option, "Toute personne disposant du lien", crée un lien similaire au vôtre. Idem pour Google Photos, Dropbox, ...
- L'avantage est que la diffusion du contenu est quelque peu limitée.
- L'inconvénient est que cela quelque peu dépend avec qui vous partagez le lien, où il est publié, etc.
Une chose à considérer est la possibilité de l'invalider facilement (en modifiant/régénérant le lien vers vos données)
Mauvaise idée. Un certain nombre de fois, j'ai vu une URL "secrète" obtenir très rapidement des hits de robot de recherche, puis découvrable par la recherche sur le Web. Une fois que j'ai même vu quelqu'un mettre en place une copie d'un site Web de bonne réputation dans un sous-dossier de son domaine, le partager avec une personne, et bientôt il a été envoyé un remarque l'avertissant que son domaine peut avoir été compromis à des fins de phishing.
Comment est-ce arrivé? Dans ce dernier cas, le navigateur Web avait une fonction anti-phishing intégrée qui envoyait les URL visitées aux services de détection de fraude. Dans les autres cas, le navigateur collectait peut-être des données de navigation et les envoyait à un moteur de recherche pour collecter les habitudes des utilisateurs.
Si vous faites cela, assurez-vous que votre robots.txt (ou en-têtes/balises META) est configuré pour dire aux moteurs de recherche de ne pas indexer le contenu.
Internet est une merveilleuse façon de rapprocher le monde, mais malheureusement, il donne à tout le monde un accès potentiellement permanent à tout ce que vous éternuez.
Si la partie secrète du chemin est assez longue, [...] ce sera difficile à deviner ou à la forcer brutalement?
Oui. Un attaquant devrait deviner le tout pour le découvrir. Puisqu'il existe de nombreuses possibilités, cela prendrait un temps infaisable.
Quels sont les problèmes avec cette approche en général?
Le problème avec cela est que les URL ne sont pas considérées comme secrètes, elles seront donc stockées dans le navigateur, dans les journaux et par tout proxy intermédiaire. De cette façon, votre URL "secrète" peut être exposée.
L'utilisation de GET rend CSRF trivial lors du traitement du contenu actif.
Non. Dans une attaque CSRF, l'attaquant falsifie une demande spécifique. Lors de l'utilisation d'un secret dans l'URL, l'attaquant ne connaît même pas l'URL correcte à laquelle forger la demande. Cela signifie que CSRF est impossible tant que l'URL est secrète.
Comme d'autres l'ont dit, ce n'est pas une bonne idée. De tels liens "secrets" qui sont utilisés pour se désinscrire ou à des fins ponctuelles similaires sont généralement de courte durée et ne sont d'aucune utilité une fois qu'ils ont été utilisés une fois.
Ma pensée initiale quand j'ai lu cette question était que l'url ne resterait pas longtemps secrète. Je pensais que peut-être Chrome (ou tout autre navigateur Web moderne) utiliserait les données de la ligne d'adresse pour initialiser une analyse. Il s'avère que ce n'est pas le cas Cependant, les chercheurs ont découvert que les plugins pouvaient toujours déclencher une analyse:
Les résultats sont assez simples: Googlebot n'est jamais venu visiter l'une ou l'autre des pages du test.
Il s'avère que deux personnes dans le test n'ont pas réellement désactivé leurs extensions, ce qui a entraîné des visites d'Open Site Explorer (quelqu'un a installé et activé Mozbar) et Yandex (en raison d'une personne différente, mais je ne suis pas clair sur quelle extension ils avaient installé et activé).
Cela signifie qu'une fois qu'un lien est utilisé, il peut être compromis par des extensions de navigateur. Et puis il n'y a pas besoin de forcer quoi que ce soit.
Quel est le but derrière ces liens? Qu'est-ce que vous, OP, essayez de réaliser? Je suis certain qu'il existe d'autres moyens d'y arriver ...
Ce serait difficile à deviner/bruteforce mais d'autres moyens d'obtenir les chemins peuvent être possibles
Par exemple, l'url peut être indexée par des services tels que google, bing, etc. Cela ferait apparaître votre URL "secrète" lorsqu'un utilisateur recherche votre page dans google. Il peut être résolu en configurant le robots.txt fichier, mais n'oubliez pas que les indexeurs peuvent l'ignorer
Les liens dans l'application peuvent rediriger vers le chemin caché
De plus, les machines du même réseau que l'utilisateur accédant à la page "secrète" ou au serveur web peuvent voir l'url, ainsi que chaque proxy intermédiaire et le FAI de l'utilisateur (ou VPN s'il en utilise un)
Enfin, l'url peut être conservée dans le cache et/ou l'historique du navigateur et dans les journaux du serveur Web et des proxys
Les requêtes GET secrètes peuvent-elles être forcées brutalement?
Oui, ils peuvent. Autant que tout type de demande sans mesures de sécurité adéquates.
Si la partie secrète du chemin est assez longue, puis-je supposer qu'il est sûr d'avoir une telle page ou zone secrète, et il sera difficile de la deviner ou de la forcer brutalement?
Non, il n'est pas sûr d'avoir une telle page ou zone secrète. Oui, il sera difficile de le deviner ou de le forcer brutalement.
Quels sont les problèmes avec cette approche en général?
Contrairement aux demandes POST, les demandes GET peuvent être facilement trouvées dans l'historique du navigateur Web.
Je pense qu'il vaudrait mieux mettre en place un mot de passe automatique ou manuel (donc vous allez décider qui peut accéder à la page) OTP One Time Password à envoyer par email.
Dans un scénario manuel:
- vous recevez la demande de [email protected]
- vous accordez l'accès à [email protected]
- le script crée le lien avec l'OTP
- le lien sera envoyé à [email protected]
- lorsque l'utilisateur [email protected] visitera la page, l'OPT sera signalé et personne d'autre ne pourra réutiliser ce lien
bien sûr, ce système nécessite une base de données où stocker le champ e-mail, OPT et indicateur autorisé