URL https avec paramètre de jeton: quel est son degré de sécurité?

https://stackoverflow.com/questions/643355

22-07-2019
|

Question

Sur notre site, nous fournissons aux utilisateurs une simulation basée sur leurs informations privées (donnée via un formulaire). Nous aimerions leur permettre de récupérer leurs résultats de simulation ultérieurement, mais sans les obliger à créer un compte avec login / mot de passe.

Nous avons envisagé de leur envoyer un courrier électronique contenant un lien leur permettant de récupérer leurs résultats. Mais naturellement, nous devons sécuriser cette URL, car des données privées sont en jeu.

Nous avons donc l'intention de transmettre un jeton (par exemple une combinaison de lettres et de chiffres ou un hachage MD5) dans l'URL et d'utiliser SSL.

Enfin, ils recevraient un courrier électronique comme celui-ci:

Bonjour,
Récupérez vos résultats sur

Était-ce utile?

La solution

SSL protégera les paramètres de la requête en transit; Toutefois, les e-mails eux-mêmes ne sont pas sécurisés et peuvent être renvoyés sur un nombre quelconque de serveurs avant d'arriver à leur destination.

En fonction de votre serveur Web, l'URL complète peut également être enregistrée dans ses fichiers journaux. En fonction de la sensibilité des données, vous voudrez peut-être que vos informaticiens n'aient pas accès à tous les jetons.

De plus, l'URL avec la chaîne de requête serait enregistrée dans l'historique de votre utilisateur, permettant ainsi à d'autres utilisateurs du même ordinateur d'accéder à l'URL.

Enfin, et ce qui rend cette situation très peu sûre, c’est l’adresse URL qui est envoyée dans l’en-tête Referer de toutes les demandes de toute ressource, même de tierce partie. Donc, si vous utilisez Google Analytics par exemple, vous allez envoyer à Google le jeton d’URL et le tout.

À mon avis, c'est une mauvaise idée.

Autres conseils

J'utiliserais un cookie pour cela. Le flux de travail devrait ressembler à ceci:

L'utilisateur accède à votre site pour la première fois.
Site définit un cookie
L'utilisateur entre les données. Les données sont stockées dans la base de données à l’aide d’une clé stockée dans le cookie.
Lorsque l'utilisateur quitte, vous lui envoyez un email avec un lien https: link
Lorsque l'utilisateur revient, le site découvre le cookie et peut lui présenter les anciennes données.

Désormais, l'utilisateur souhaite utiliser un navigateur différent sur une autre machine. Dans ce cas, proposez un "transfert". bouton. Lorsque l'utilisateur clique sur ce bouton, il recevra un "jeton". Elle peut utiliser ce jeton sur un autre ordinateur pour réinitialiser le cookie. De cette manière, l’utilisateur décide du niveau de sécurité auquel il souhaite transférer le jeton.

SSL sécurise le contenu des données en transit, mais je ne suis pas sûr de l'URL.

Quoi qu’il en soit, un moyen d’atténuer la réutilisation de ce jeton d’URL par un attaquant consiste à s’assurer que chaque jeton ne peut être utilisé qu’une seule fois. Vous pouvez même définir un cookie pour que l'utilisateur légitime puisse continuer à utiliser le lien, mais après le premier accès, il ne fonctionnera plus que pour une personne possédant le cookie.

Si le courrier électronique de l'utilisateur est compromis et qu'un attaquant obtient le lien en premier, eh bien, vous êtes blessé. Mais l'utilisateur a également de plus gros problèmes.

Les courriers électroniques sont intrinsèquement peu sécurisés. Si quelqu'un peut cliquer sur ce lien et accéder aux données, vous ne les protégez pas vraiment.

Le jeton est sécurisé lorsqu'il est transmis via SSL. Le problème que vous allez avoir, c'est que les personnes (celles à qui elles ne sont pas destinées) peuvent accéder à l'URL.

S'il s'agit d'informations confidentielles telles que SSN, je ne pense pas que j'enverrais une URL par courrier électronique. Je préférerais qu'ils créent un nom d'utilisateur et un mot de passe pour le site. Il est trop facile de compromettre un courrier électronique avec ce type d'informations en jeu pour vous et pour eux. Si le compte de quelqu'un est comprimé, il se demandera qui en est réellement responsable. Plus vous êtes en sécurité, mieux vous êtes, du point de vue strictement de l'ACY.

Je ne voudrais vraiment pas que cela soit considéré comme suffisamment sûr pour une situation où il existe de graves problèmes de confidentialité. Le fait que vous envoyez l'URL dans un courrier électronique (probablement en texte clair) est de loin le lien le plus faible. Après cela, il y a un risque d'attaques brutales sur les jetons, qui (sans la structure d'un véritable mécanisme d'authentification) risquent d'être plus vulnérables qu'une configuration de nom d'utilisateur et de mot de passe bien construite.

Incidemment, les paramètres d'une requête https ne posent aucun problème.

Dans l’état actuel des choses, ce serait une mauvaise idée. Vous allez scarifier la sécurité avec une utilisation facile. Comme indiqué précédemment, SSL ne protégera que le transfert d'informations entre le serveur et le navigateur client et empêchera uniquement l'attaque par l'intermédiaire. Les courriels sont très risqués et peu sûrs.

Le mieux serait une authentification du nom d'utilisateur et du mot de passe pour accéder aux informations.

J'aime plus ou moins l'idée de cookie. Vous devez également chiffrer les informations de cookie. Vous devez également générer le jeton avec le sel et la phrase clé, ainsi que le $ _SERVER ['HTTP_USER_AGENT'] pour limiter la probabilité d'une attaque. Stockez autant d'informations non sensibles sur le client dans le cookie à des fins de vérification.

La phrase clé peut être stockée dans le cookie pour une utilisation facile, mais gardez à l’esprit que le cookie peut également être volé = (.

Il est préférable de laisser le client taper la phrase clé qu'il a fournie, qui est également stockée dans la base de données avec ses données.

Ou bien, la clé peut être utilisée si la personne utilise une machine différente, différente des paramètres $ _SERVER ['HTTP_USER_AGENT'] ou manque simplement le cookie. Ainsi, le cookie peut être transféré ou défini.

Assurez-vous également que les données sensibles sont cryptées dans la base de données. On ne sait jamais;)

Vous savez que si un pirate informatique accède à votre base de données, de nombreuses informations personnelles peuvent être librement communiquées?

Après cela, je dirais que ce n’est pas une mauvaise idée. Je ne voudrais pas utiliser MD5 ou SHA1 car ils ne sont pas très sécurisés pour le hachage. Ils peuvent être "décryptés". (Je sais que ce n'est pas le cryptage) assez facilement.

Sinon, j'utiliserais peut-être une deuxième information qui ne serait pas envoyée par courrier électronique, genre de mot de passe. La raison en est assez simple, si quelqu'un accède au courrier électronique de l'utilisateur (assez facile avec hotmail si vous ne tuez pas votre session), il aura accès à toutes les informations que l'utilisateur a envoyées.

Notez que le protocole HTTPS sécurisera et cryptera les données envoyées par votre site à l'utilisateur final. Rien d’autre, prenez-le comme un tunnel sécurisé. Rien de plus rien moins.

D'après ce que j'ai compris de votre idée, en théorie, quelqu'un pourrait taper une chaîne aléatoire de 40 caractères ou un hachage MD5 et obtenir les détails de quelqu'un d'autre. Bien que cela puisse être hautement improbable, cela ne doit se produire qu'une seule fois.

Une meilleure solution consiste peut-être à envoyer un jeton à l'utilisateur, puis à lui demander de saisir certains détails, tels que son nom, son code postal, son SSN ou une combinaison de ceux-ci.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow