Sécurité: ASp.NET Identity HTTPOnly Cookie avec SSL

Question

Ceci est une question générale car je suis habitué à l'objet utilisateur stocké dans la session et j'apprends le nouveau cadre d'identité.

Je vois beaucoup parler de l'envoi de "revendications" en dehors du cookie. De cette façon, vous n'avez pas besoin de re-rechercher les informations de l'utilisateur. Cela signifie que le nom, l'adresse e-mail ou même les autorisations sont en dehors de la zone de réclamation du cookie enregistré. Tout ce que j'ai étudié à ce sujet, httpOnly sur SSL est très sûr en termes d'être piraté. J'hésite à envoyer autre chose qu'un ID utilisateur pour identifier l'utilisateur, puis rechercher le reste dans la base de données pour m'assurer qu'au moins si l'utilisateur est piraté, les autorisations ne sont pas piratées. Suis-je trop prudent?

Je vois aussi les gens mettre les cookies à expiration dans 7 jours ou 1 jour ect ... En ce qui concerne cela et vous envoyez les permissions/rôles dans la zone de réclamations. Que se passe-t-il s'ils changent sur le serveur. Fondamentalement, il semble que l'utilisateur devrait se connecter et se déconnecter pour que les nouvelles autorisations puissent avoir lieu. Se demandait est-ce que l'attente de norme avec les normes de l'interface utilisateur du logiciel?

Merci d'avance pour vos pensées :)

Angela

Answer 1

Pardonnez mon ignorance, mais je l'ai pas rencontré un logiciel où les demandes seraient envoyées dans les cookies. En règle générale, le problème avec les cookies est la possibilité de XSS (Cross-site scripting) attaques parce que les navigateurs sont écrits pour toujours les envoyer. Ce que les gens ont tendance à faire ces jours-ci est d'utiliser un mécanisme d'authentification fédérée, où le fournisseur d'identité (page de connexion) et le fournisseur d'accès (le code de l'application) ne sont pas nécessairement connectés. . Cela signifie que les données de l'utilisateur que vous pourriez rechercher dans la base de données n'existent que dans le fournisseur d'identité et que le fournisseur de services doit gérer tout ce que le fournisseur d'identité fournit.

C'est pourquoi chaque bit d'information est envoyé dans une 'revendication'. Cela signifie que l'IdP prétend que le nom d'utilisateur est john.smith, mais que SP ne dispose d'aucun moyen pour le vérifier. Pour que cela fonctionne, l'IdP et le SP doivent avoir établi une forme de confiance, généralement sous la forme de clés de signature pré partagées qui permettent à l'IdP de signer le jeton (enveloppe SAML ou JWT, par exemple) et le SP vérifier la signature pour pouvoir vérifier que le jeton n'a pas été falsifié. En règle générale, ce jeton n'est jamais utilisé en tant que cookie; à la place, il est ajouté à un en-tête Authorization, en utilisant normalement le schéma Bearer. En outre, en remarque - lorsque vous dites que vous êtes familiarisé avec l'utilisation des sessions, vous devez comprendre qu'un suivi de session est également un cookie (dans ASP.NET). Le serveur dispose d'informations sur un utilisateur stocké dans le cache mémoire du pool d'applications et le navigateur continue d'envoyer le cookie en disant «ici je suis». Donc, la sécurité, il y a un niveau comparable entre simplement utiliser des cookies ou utiliser des cookies + session. Bien sûr, on pourrait prétendre qu'un cookie pourrait divulguer des informations, mais une application pourrait toujours marquer les données ou chiffrer le cookie en entier, annulant cet argument.