URL https avec paramètre de jeton: quelle est sa sécurité?


89

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

Nous avons pensé à leur envoyer un email avec un lien, à partir duquel ils pourraient récupérer leurs résultats. Mais, naturellement, nous devons sécuriser cette URL, car les données privées sont en jeu.

Nous avons donc l'intention de transmettre un jeton (comme une combinaison de 40 caractères de lettres et de chiffres, ou un hachage MD5) dans l'URL et d'utiliser SSL.

Enfin, ils recevraient un e-mail comme celui-ci:

Bonjour,
récupérez vos résultats sur https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Qu'est-ce que tu en penses? Est-ce suffisamment sécurisé? Que me conseilleriez-vous pour la génération de jetons? Qu'en est-il de la transmission de paramètres d'URL dans une requête https?


Réponses:


97

SSL protégera les paramètres de requête en transit; cependant, l'e-mail lui-même n'est pas sécurisé et l'e-mail pourrait rebondir sur n'importe quel nombre de serveurs avant d'arriver à sa destination.

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

En outre, l'URL avec la chaîne de requête serait enregistrée dans l'historique de votre utilisateur, permettant à d'autres utilisateurs de la même machine d'accéder à l'URL.

Enfin, et ce qui rend cela très peu sûr, c'est que l'URL est envoyée dans l'en-tête Referer de toutes les demandes pour toute ressource, même des ressources tierces. Donc, si vous utilisez Google Analytics par exemple, vous enverrez à Google le jeton URL et tout à eux.

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


1
Je n'avais pas pensé au problème du référent HTTP, mais le lien URL redirigerait vers la page de résultats, ce ne serait pas une page appropriée (pas de Google Analytics ou autre script tiers).
Flackou

5
La plupart des navigateurs ne suppriment-ils pas le référent lorsqu'ils passent de HTTPS à HTTP?
Kevin Mark

2
C'est similaire au lien d'activation de l'utilisateur (ou de réinitialisation du mot de passe), n'est-ce pas? Comment alors cette affaire devrait-elle être traitée? De nombreux sites Web envoient des URL de réinitialisation aux e-mails, POST n'est pas une option car il devrait être cliquable. Merci.
pinkpanther

3
Donc, quelle est la solution?
RT

1
que se passe-t-il si le jeton dans l'url n'est pas le même que le jeton utilisé pour les requêtes API et qu'il ne dure qu'une heure, quel serait alors le mal?
user1709076

13

J'utiliserais un cookie pour cela. Le flux de travail devrait être comme ceci:

  1. L'utilisateur vient sur votre site pour la première fois.
  2. Le site définit un cookie
  3. L'utilisateur entre les données. Les données sont stockées dans la base de données à l'aide d'une clé qui est stockée dans le cookie.
  4. Lorsque l'utilisateur quitte, vous lui envoyez un e-mail avec un lien https:
  5. Lorsque l'utilisateur revient, le site découvre le cookie et peut présenter à l'utilisateur les anciennes données.

Désormais, l'utilisateur souhaite utiliser un navigateur différent sur une autre machine. Dans ce cas, proposez un bouton «transfert». 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 façon, l'utilisateur décide de la sécurité dans laquelle elle souhaite transférer le jeton.


4

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, une façon de limiter la réutilisation de ce jeton 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 afin que l'utilisateur légitime puisse continuer à utiliser le lien, mais après le premier accès, il ne fonctionnera que pour quelqu'un avec le cookie.

Si l'e-mail de l'utilisateur est compromis et qu'un attaquant obtient le lien en premier, eh bien, vous êtes détenu. Mais l'utilisateur a aussi de plus gros problèmes.


11
La connexion SSL est sécurisée avant la transmission de l'URL.
David

1

Le courrier électronique est intrinsèquement non sécurisé. Si quelqu'un peut cliquer sur ce lien et accéder aux données, vous ne les protégez pas vraiment.


Exact, mais de nombreux sites ne s'en soucient pas et envoient des identifiants / mots de passe par courrier. Mais ce n'est pas une raison de les imiter ...
Flackou

Je n'accepte aucune raison de les imiter, mais ils vous disent généralement de changer le mot de passe après votre première connexion.
Jason Punyon

1

Eh bien, le jeton est sécurisé lorsqu'il est passé via SSL. Le problème que vous allez avoir est qu'il est disponible pour les gens (ceux à qui il n'est pas destiné) en pouvant afficher l'URL.

S'il s'agit d'informations privées comme le SSN, je ne pense pas que j'enverrais une URL par e-mail. 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 e-mail avec ce type d'informations en jeu pour vous et pour eux. Si le compte de quelqu'un est compromis, il sera remis en question de qui est vraiment la faute. Plus vous êtes en sécurité, mieux vous êtes d'un point de vue strictement CYA.


1
Vous avez raison: l'URL resterait dans l'historique du navigateur par exemple
Flackou

0

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

Il n'y a aucun problème avec les paramètres dans une requête https, d'ailleurs.


Vous avez raison sur le risque d'attaques par force brute. Je ne vois pas comment nous pourrions empêcher les robots de ce type d'attaque. Interdire les IP "insister" ne serait pas une protection suffisante. Auriez-vous des idées sur le sujet?
Flackou

En fait, avec le type d'espace clé dont nous parlons, mettre un if (this_ip_number_has_requested_an_invalid_token_today ()) sleep (5); dans votre script load_simulation serait une protection parfaitement suffisante. (La limitation de débit est l'une de ces caractéristiques des bons mécanismes d'authentification.)
chaos

Merci pour votre réponse. Mais je pensais qu'un même bot pouvait facilement prendre différentes adresses IP, ce qui rendait la limite de débit IP insuffisante. Ai-je tort?
Flackou

Tout ce qui les obtient est une tentative non retardée par IP. L'espace d'adressage IP n'est pas si facilement disponible que cela soit utile.
chaos

0

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 n'empêchera que l'attaque d'intermédiaire. Les e-mails sont très risqués et peu sécurisés.

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

J'aime plus ou moins l'idée des cookies. Vous devez également crypter les informations des cookies. Vous devez également générer le jeton avec le sel et la phrase clé plus 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é = (.

Mieux vaut 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, la clé peut être utilisée au cas où la personne utilise une machine différente qui diffère dans les 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 ;)


-1

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

Après cela, je dirais que ce n'est pas une mauvaise idée. Je n'utiliserais pas 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 du cryptage) assez facilement.

Sinon, j'utiliserais peut-être une deuxième information qui ne serait pas envoyée par e-mail comme un mot de passe. La raison 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 HTTPS sécurisera et cryptera les données envoyées de votre site à l'utilisateur final. Rien d'autre, prenez-le comme un tunnel sécurisé. Rien de plus rien de moins.


Comment un hachage SHA1 salé est-il déchiffré dans n'importe quel sens du mot?
Eli

"Vous savez que si un pirate informatique accède à votre base de données, de nombreuses informations personnelles peuvent être librement données?" Oui, mais n'est-ce pas un problème pour tous les sites Web ??
Flackou

@Flackou oui, mais si vous avez accès à la base de données de paypal, vous ne trouverez pas les informations de carte de crédit clairement enregistrées, tout est crypté. @Eli: theregister.co.uk/2005/02/17/sha1_hashing_broken
Erick

-1

D'après ce que je comprends 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 pourrait être d'envoyer un jeton à l'utilisateur, puis de lui demander de saisir certains détails, tels que son nom, son code postal, ssn ou une combinaison de ceux-ci.


5
SSN? Es-tu sérieux? Quoi qu'il en soit, je vous suggère de faire le calcul sur le nombre de chaînes aléatoires de 40 caractères. C'est plus que "hautement improbable"
Eli

Vous avez raison, nous devrions probablement ajouter un autre paramètre dans l'url, comme l'email (même si a..z + A..Z + 0..9 = 62 caractères, et 62 ^ 40 est un nombre assez grand).
Flackou

Les gars, 62 ^ 40 est considérablement plus que le nombre d'atomes dans l'univers. C'est littéralement impossible à deviner.
Eli

1
Je suis surpris de voir combien de personnes ne peuvent pas saisir l'ampleur de ces chiffres. Si vous deviniez un MILLION de jetons par seconde, il est beaucoup plus probable que le soleil s'éteigne avant que vous n'obteniez un coup
Eli

4
Richard, on dirait que vous faites remarquer ce que l'on appelle habituellement le paradoxe de l'anniversaire ... ce n'est pas seulement le nombre de combinaisons possibles qui compte, mais combien d'entre elles sont utilisées. Eh bien, dans ce cas, vous devez utiliser environ 2 ^ 119 des 62 ^ 40 combinaisons avant que la chance ne devienne significative.
erickson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.