Les URL aléatoires sont-elles un moyen sûr de protéger les photos de profil?
Je souhaite passer d'ID utilisateur séquentiels à des ID utilisateur aléatoires, afin de pouvoir héberger publiquement des photos de profil, c'est-à-dire example.com/profilepics/asdf-1234-zxcv-7890.jpg.
Combien de temps les ID utilisateur doivent-ils être pour empêcher quiconque de trouver des photos d'utilisateurs pour lesquelles il n'a pas reçu le lien?
16 lettres minuscules et zéro à neuf offrent-elles une complexité raisonnable? Je fonde ça sur 3616 = 8x1024, estime prudemment que 10 milliards de comptes d'utilisateurs réduisent l'espace à 8 x 1014. À 1000 suppositions/seconde, il faudrait 25 000 ans pour trouver un compte. A moins que j'oublie quelque chose.
Cela dépend entièrement de ce que vous entendez par "sûr".
Si votre seul problème est qu'un attaquant devine des URL, alors 16 caractères alphanumériques donnent environ 8 000 000 000 000 000 000 000 000 000 d'adresses possibles, ce qui est suffisant pour empêcher les suppositions aléatoires - afin qu'un attaquant ait 50% de chances de trouver une seule image sur un site avec mille utilisateurs en un an, ils auraient besoin de faire 100 trillions d'essais par seconde, suffisamment de trafic pour faire tomber même quelque chose comme Amazon ou Google.
Mais il y a d'autres façons de fuir les URL: les gens qui les mettent dans des courriels ou des articles de blog, des robots d'indexation qui trouvent des pages que vous n'avez pas sécurisées correctement, etc. Si vous avez vraiment besoin de protéger quelque chose, vous devez le mettre derrière le même type de sécurité que le reste de votre site Web.
Personnellement, pour créer des URL difficiles à deviner, j'utiliserais des GUID/UUID. L'espace de recherche est absurdement énorme, vous n'avez pas besoin de coordonner la génération entre plusieurs serveurs et la plupart des langues ont des routines standard pour les gérer.
Ce n'est peut-être pas la réponse à votre question, mais si vous souhaitez "masquer" l'emplacement de vos photos de profil sur un site Web, vous pouvez simplement incorporer l'image en tant qu'URI de données. Vous pouvez coder en base64 l'image sur votre serveur et incorporer la chaîne sur votre site Web, au lieu d'exposer des chemins d'image.
voir http://css-tricks.com/data-uris/ et http://css-tricks.com/examples/DataURIs/ pour une description et une démonstration.
Puisque vous avez déjà évoqué Dropbox, je pense que nous pouvons donner au moins une raison pour laquelle faire cela est une mauvaise idée:
Dropbox désactive les anciens liens partagés après la fin des déclarations de revenus sur Google
La faille, qui serait également présente sur Box, affecte les fichiers partagés contenant des hyperliens. "Les utilisateurs de Dropbox peuvent partager des liens vers n'importe quel fichier ou dossier dans leur Dropbox", a noté la société hier tout en confirmant la vulnérabilité:
Les fichiers partagés via des liens ne sont accessibles qu'aux personnes disposant du lien. Cependant, des liens partagés vers des documents peuvent être divulgués par inadvertance à des destinataires non intentionnels dans le scénario suivant:
- Un utilisateur Dropbox partage un lien vers un document contenant un lien hypertexte vers un site Web tiers.
- L'utilisateur, ou un destinataire autorisé du lien, clique sur un lien hypertexte dans le document.
- À ce stade, l'en-tête du référent révèle le lien partagé d'origine vers le site Web tiers.
- Une personne ayant accès à cet en-tête, comme le webmaster du site Web tiers, pourrait alors accéder au lien vers le document partagé.
Fondamentalement, il est trop facile pour les URL de fuir par inadvertance, compte tenu du nombre d'utilisateurs qui les utilisent. Si vos utilisateurs sont éduqués à ce sujet et évitent ces problèmes, je suppose que c'est raisonnablement sûr, mais c'est une grande hypothèse à faire.
Les autres réponses sont généralement bonnes, mais une autre considération est le transport. Si vous utilisez http simple ou tout autre protocole non crypté (ou envoyez les URL par e-mail), toutes les données que vous transmettez et recevez, y compris ces URL, doivent être considérées comme entièrement publiques du point de vue de la sécurité. Une grande partie (quiconque a des statistiques?) Des utilisateurs sont sur des points d'accès wifi publics sans cryptage et le raclage actif d'url/image de ces réseaux est courant.
Comme mentionné par d'autres, un URI pour une image spécifique fuira tôt ou tard, quelle que soit sa longueur ou son alambic. Si vous souhaitez restreindre l'affichage aux utilisateurs connectés, vous pouvez utiliser, par exemple, .../image/profile.php?u=12345 pour afficher l'image de l'utilisateur 12345 sans qu'un direct URI à la photo soit disponible pour être diffusé au grand public. On suppose que des personnes aléatoires (non connectées) ne retireraient rien de profile.php. Notez que rien n'empêche un utilisateur connecté d'enregistrer cette image (surtout si elle est mise en cache) et de la transmettre. Il y a des choses qui pourraient être faites avec des en-têtes de contrôle de cache, etc., ou en mettant l'image dans Flash, ou autre chose, mais si une image est visible sur le navigateur de quelqu'un, avec suffisamment de travail, il sera possible de la saisir et de l'enregistrer.
Le problème avec votre schéma est que les nombreux utilisateurs de vos URL ne devineront probablement pas tous qu'ils contiennent des informations sensibles. Et une partie de ce problème est que vous n'avez probablement aucune idée de la taille de la base d'utilisateurs; pour ces URL, les utilisateurs incluent
Les personnes que vous considérez comme des utilisateurs.
Leurs plugins/addons/extensions de navigateur.
À peu près n'importe quel contenu tiers sur votre site (publicités, analyses, plugins sociaux, ...) informera probablement, d'une manière ou d'une autre, des tiers des URL en question.
Sites Web apparemment aléatoires qui voient l'URL comme URL de référence (savez-vous vraiment quels liens supplémentaires curieux vos utilisateurs invoquent dans votre site Web via des modules complémentaires de navigateur?).
La preuve empirique est que les URL https uniquement annoncées comme équivalentes à un mot de passe sont indexées par Google, à plusieurs reprises, par exemple dans le cas du portefeuille en ligne sans mot de passe Bitcoin Instawallet (notez qu'ils ont tellement fait faillite qu'ils ne s'offrent même plus un certificat SSL valide).
Ajouter quelques points importants, car tout le monde a répondu ci-dessus semble avoir manqué certains d'entre eux.
- La probabilité d'exposer une URL par inadvertance est plus élevée que d'exposer un mot de passe car les gens savent que le mot de passe est sensible.
- Facebook comme les sites Web utilisent des URL CDN qui sont si complexes que personne ne peut le deviner, mais pourtant, d'un point de vue de la sécurité, elles semblent être risquées car la révocation de l'accès est impossible lorsque l'utilisateur modifie les paramètres de confidentialité. Certains sites Web, y compris ceux avec le stockage s3 d'Amazon Web Service dans le backend, utilisent une URL signée avec un horodatage qui sera validé périodiquement.
- Google Cache! Les moteurs de recherche sont susceptibles de parcourir les images prétendument privées. Faites une recherche avec dorks qui ne ramènerait que les résultats des CDN Facebook et vous serez étonné.