Générer des URL uniques qui peuvent être révoquées
J'ai une obligation de générer une URL à usage unique qui devrait avoir les fonctionnalités suivantes:
- Comme les paramètres de requête URL peuvent contenir des informations sensibles, elles doivent être chiffrées (en plus du chiffrement
https). - Une fois utilisée, l'URL ne peut plus être utilisée.
- Les URL expirent automatiquement après un certain temps.
- Un administrateur doit pouvoir révoquer une URL valide. Si l'utilisateur essaie ultérieurement d'utiliser cette URL, il devrait voir un message d'erreur approprié.
Pour ce faire, je peux penser à deux approches de haut niveau:
- Générez un nombre aléatoire comme paramètre de requête de l'URL. Stockez le nombre aléatoire et les paramètres correspondants (c'est-à-dire les paramètres de requête réels, l'expiration, l'état de révocation, l'état utilisé) dans une base de données. Lorsque l'utilisateur utilise l'URL, vérifiez toutes les conditions préalables requises et marquez-les comme utilisées avant de fournir les paramètres de requête réels.
- Incorporez les paramètres de requête réels et l'horodatage d'expiration comme paramètre de requête de l'URL. Chiffrez l'URL avec un algorithme tel que AES256. Cependant, j'aurais encore besoin de stocker l'URL dans une base de données afin de fournir la fonction de révocation.
Sur la base de ce qui précède, je penche vers l'option 1 car toute la logique est en un seul endroit et elle semble plus sécurisée. Existe-t-il des meilleures pratiques de l'industrie pour traiter ce type de problème?
Si cela est important, ce sera un service Web basé sur REST hébergé sur IIS.
On dirait que vous avez une assez bonne idée de ce que vous faites.
Le modèle de lien unique est assez courant pour des choses comme la vérification des e-mails. En règle générale, vous stockez la date d'expiration dans une base de données et/ou utilisez une chaîne signée dans l'URL qui inclut l'expiration dans la chaîne à signer. Ce ne sont que des précautions pour éviter de faire confiance à la saisie de l'utilisateur.
Si vous voulez être vraiment approfondi, vous pouvez leur envoyer l'ID aléatoire ou l'URL du jeton, puis stocker un hachage dans la base de données pour éviter que quelqu'un n'utilise le jeton en cas de violation de données.
Vous êtes assez vague sur le contexte des paramètres chiffrés AES proposés. J'inclurais généralement des informations sensibles qui ne sont pas nécessaires pour le routage d'URL dans un corps de message, au lieu de l'URL. De cette façon, il n'apparaît pas dans les journaux du serveur Web ou du proxy. Les données cryptées AES peuvent également vous pousser assez rapidement à dépasser la limite de longueur d'URL, selon la taille du contenu en texte brut.
Modifier: Pour être complet, Azure Storage SAS Tokens sont un excellent exemple de cryptographie méthode qui ne nécessite aucun enregistrement de base de données et qui est révocable. La révocation se fait en modifiant la clé API du service ... qui révoquerait les jetons tous émis par la même clé.
Étant donné que je n'ai pas beaucoup d'informations sur le système utilisé, je recommanderais la recherche de base de données plus simple que toute solution nécessitant des mesures sophistiquées sur le plan cryptographique.
De plus, pour que les méthodes cryptographiques fonctionnent comme un lien à usage unique, certains paramètres connus du service et inclus dans l'URL doivent être modifiés lorsque le lien est utilisé. Ce paramètre ne doit pas nécessairement être une recherche de base de données, mais il doit y avoir une modification persistante. Par exemple, si le lien est une URL de téléchargement unique, la présence d'un fichier dans le répertoire de téléchargement peut invalider l'URL.
Enfin, la valeur stockée dans la base de données est plus simple car il n'y a qu'une seule source pour vérifier la validité. Avec la solution sans base de données, vous devez vérifier le secret (c'est-à-dire la clé de cryptage), ainsi que tout facteur qui invalide le lien après la première utilisation.
L'utilisation de la cryptographie symétrique pour un paramètre d'URL vous donnerait un avantage: elle élimine le besoin de rechercher une base de données. L'inconvénient est que vous introduisez un secret (la clé de cryptage) que vous devez protéger et maintenir. Étant donné que vous devrez de toute façon effectuer la recherche dans la base de données pour vérifier l'état de révocation, vous n'aurez aucun avantage. Je choisirais donc l'approche n ° 1.
Assurez-vous d'utiliser des ID: s suffisamment longs et générez-les avec un CSPRNG. Et comme nbering le dit, assurez-vous de les hacher (sans sel) pour vous protéger en cas de violation.
Les géants du logiciel comme Google utilisent une méthode d'URL signées
La prémisse est simple, vous envoyez une demande avec une chaîne chiffrée qui correspond au côté non chiffré de la requête. Il ne vous reste plus qu'à le déchiffrer sur le serveur.
Par exemple
example.com?file=file.ext&time={unixtimecode}&{encryptedstringthatmatchesfileandtimestamp}
L'utilisation de la clé de chiffrement est destinée à garantir que le serveur/une personne ayant accès à la clé a fait la demande qu'un utilisateur peut suivre pendant un certain temps et que la demande n'a pas été falsifiée. La révocation de la chaîne peut être aussi simple que la suppression d'une clé de chiffrement temporaire, ce qui signifie que le serveur ne pourra pas déchiffrer la demande, même si elle a été mise en cache.