Est-il suffisant de sécuriser une page d'état de commande uniquement par une URL aléatoire?

11

Après qu'un client (d'entreprise) a acheté des articles dans notre boutique en ligne, nous envoyons un e-mail avec un aperçu de ce qu'il lui a acheté.

Nous aimerions informer notre client des paiements reçus, du suivi des paquets, etc. Je résoudrais cela en attribuant à chaque commande un ID aléatoire et en ajoutant un lien à chaque courrier. Le lien peut être comme ceci: http://shop.foo.bar/order/rwklvc46g9wt7kvy09f1

Prendriez-vous des mesures supplémentaires pour protéger les données? Ou choisissez une solution complètement différente?

Avantages:

  • aucune mise à jour du statut annyoing par mail (surtout si des mises à jour fréquentes se produisent)
  • source d'information unique (jamais obsolète)
  • partageable (par exemple avec son patron ou ses collègues)

Désavantages:

  • données privées exposées sur un site Web accessible au public (par exemple, numéros de téléphone, détails de paiement)
security privacy Dan Elpat
la source
4
Salut Dan, bienvenue aux Webmasters. Vous semblez avoir créé deux utilisateurs identiques (?) Et modifié votre question avec l' autre "Dan" - à cause de cela, il est dans une file d'attente en attente d'approbation. L'utilisateur qui pose la question peut toujours éditer ses propres questions librement et faire des commentaires sur les réponses, etc. L'autre "Dan" n'a pas assez de réputation pour faire l'un ou l'autre - parce qu'il n'a pas posé la question.
MrWhite

Réponses:

8

Sans sécurité supplémentaire, non. Les URL aléatoires sont constamment explorées. Cependant, cela est bon lorsque vous avez terminé avec une page de connexion pour authentifier l'utilisateur.

Une solution intermédiaire consiste à s'assurer que la page d'état ne contient aucune donnée personnelle, uniquement des informations générales. Par exemple, «PAYÉ PAR CC» plutôt que «PAYÉ PAR VISA 1234567891» et «Expédié» au lieu de «Expédié à John Doe, 123 Blue Street», etc.

Itai
la source
0

Je pense que vous devriez protéger davantage ces données. En ce qui concerne la simplicité du système, je suis tout à fait d'accord pour dire que les URL publiques avec une chaîne aléatoire et unique sont suffisantes et pratiques.

Cependant, si des méthodes de paiement (y compris les informations de carte de crédit), des e-mails ou des téléphones vont être affichés, vous devez protéger ces données. Cela dépend également de la partie du monde que vous êtes, mais dans la plupart d'entre eux, ce besoin s'étend aux questions juridiques et à la protection des données des utilisateurs.

Ce que la plupart des sites Web d'achat font pour ce type de situations, c'est demander des informations d'identification (identifiant / mot de passe) ou un numéro de suivi avec un code de suivi, ou quelque chose que seul l'utilisateur ou les parties de confiance de l'utilisateur peuvent avoir.

Alpha
la source
-1

Oui, cela suffit tant que:

  1. vous envoyez simplement le lien par e-mail et ne le soumettez pas à Google. Mais selon votre question, c'est ce que vous faites, donc il n'y a aucun moyen pour Google de connaître le lien à cet effet, il ne sera jamais indexé / exploré.

  2. vous rendez l'ID utilisé dans le lien aléatoire et suffisamment long. Si ce n'est pas aléatoire, mais que vous utilisez un entier incrémentiel simple comme ID, l'un de vos clients pourrait facilement remarquer qu'en entrant des nombres incrémentiels simples dans le lien, il pourrait lire toutes les autres commandes. Si c'est aléatoire, mais pas assez long (disons qu'il n'est composé que de 4 chiffres / lettres), il serait facile, même avec un PC à la maison, d'attaquer par force vos commandes, j'aurais juste besoin d'essayer (26 + 10) ^ 4 = 1 679 616 combinaisons possibles. Disons que je lance un script qui essaie un lien par seconde, il faudrait au script moins de 20 jours pour forcer tous les liens possibles et lire toutes vos commandes.

  3. IMPORTANT: pour plus de sécurité, vous devez supprimer le lien après un certain nombre de jours (c'est-à-dire après 1 mois). C'est l'astuce pour le sécuriser. De cette façon, même si quelqu'un essaie de forcer brutalement vos liens, il aurait besoin d'une énorme puissance de calcul, sinon son attaque ne sera jamais assez rapide pour essayer toutes les combinaisons possibles avant d'être supprimées. Et même s'il a une énorme puissance de calcul, il serait à peine capable de tester plus d'un lien par seconde car le serveur qui gère vos commandes pourrait commencer à refuser sa connexion s'il essaye de se connecter plusieurs fois par seconde. FYI: la suppression du lien, ne signifie pas que vous devez supprimer tout l'ordre dans DB. Vous pouvez utiliser une autre clé primaire pour la table des commandes (un simple auto-incrémentation int) et vous pouvez utiliser un champ UNIQUE (qui autorise NULL) appelé link_id qui est celui que vous entrez dans link. Après un mois, il vous suffit de supprimer la valeur de link_id et de la définir NULL. De cette façon, la commande sera toujours dans le tableau et visible depuis votre panneau d'administration, mais le lien direct ne sera plus valide pour afficher directement la page de commande.

Marco Demaio
la source