Les services de liens courts à identifiants séquentiels reçoivent plus de requêtes d'énumération que ceux à identifiants aléatoires

Hypothèse

La fiche OWASP sur les références directes non sécurisées à un objet recommande des contrôles d'accès sur chaque objet et, en défense en profondeur, des identifiants complexes qu'il est impraticable de deviner. Un lien court est par construction un objet public sans contrôle d'accès, si bien que l'identifiant est la seule chose qui sépare un lien d'un inconnu. Avec une clé séquentielle (un compteur encodé en base62), un client qui connaît une clé peut demander ses voisines et atteindre chaque lien jamais créé ; avec une clé aléatoire de longueur fixe, la plupart des essais échouent. L'hypothèse est que les deux conceptions produisent un trafic visiblement différent : sur un service séquentiel, une part plus importante des redirections réussies provient de clients qui n'ont jamais reçu le lien (ils arrivent sans référent, dans un ordre monotone de clés, depuis un petit nombre de sources réseau, à des intervalles de type machine), tandis que sur un service à clés aléatoires, ces mêmes clients produisent surtout des réponses 404. Une affirmation secondaire est que le taux brut de 404 seul ne sépare pas les deux cas, car un service à clés aléatoires voit des essais qui échouent et un service séquentiel voit des essais qui réussissent.

Prédiction

Pour deux services de taille et d'ancienneté comparables, les sessions reconstruites à partir des journaux d'accès (un client, une heure) montreront, sur le service séquentiel, une part mesurable de sessions qui demandent de nombreuses clés existantes distinctes en ordre croissant ou décroissant, sans référent ; sur le service à clés aléatoires, cette part est proche de zéro et les mêmes clients apparaissent plutôt sous forme de rafales de 404. Bloquer ou limiter le débit de ces sessions sur le service séquentiel réduit sensiblement son volume de redirections réussies ; sur le service à clés aléatoires, cela change peu de chose.

Test proposé

1. Prendre les journaux d'accès d'un service de chaque type sur la même période, ou d'un même service avant et après un changement de génération des clés, avec clé, statut, présence d'un référent, réseau du client et horodatage.
2. Reconstruire les sessions et étiqueter une session comme énumérative lorsqu'elle demande plus d'un certain seuil de clés distinctes, majoritairement adjacentes dans l'ordre des clés, sans référent.
3. Rapporter, pour chaque service, la part des redirections réussies attribuable à des sessions énumératives, la part de 404, et le nombre de clés distinctes atteintes par de telles sessions.
4. Publier les règles d'étiquetage et les seuils afin qu'un autre opérateur puisse les appliquer à ses propres journaux.

Statut

Aucun résultat n'est affirmé ici. Parmi les facteurs de confusion figurent les robots d'indexation qui suivent des liens de façon légitime, les différences dans la manière dont les deux services sont annoncés, et des limitations de débit qui masquent déjà le comportement dans l'un des deux journaux ; le test devrait consigner les limitations de débit en vigueur.