signe unique sur les cookies enlevé par un logiciel anti-spyware

Nous avons un seul signe sur la mise en œuvre pour une famille de sites Web où le cookie d'authentification provient du domaine racine (par exemple bar.com), leur permettant d'être connecté à un domaine enfant (par exemple, foo.bar.com). L'implémentation est en C# en utilisant l'authentification par formulaire .net standard.signe unique sur les cookies enlevé par un logiciel anti-spyware

Malheureusement, certains de nos utilisateurs font supprimer leurs cookies d'authentification par un logiciel anti-spyware. J'ai été capable de recréer cette situation en utilisant PC Tools Anti Spyware et IE8. Le résultat pratique est que les utilisateurs se connectent au site, naviguent vers une autre page et se voient ensuite demander de se connecter à nouveau.

Le cookie est signalé comme un cookie de suivi à faible risque par le logiciel anti-spyware.

Yat-il un moyen de rendre le cookie plus acceptable pour les goûts apparemment plutôt pointilleux des logiciels anti-spyware de notre utilisateur?

Mise à jour:

Je l'ai regardé dans le premier "" question et c'est un hareng rouge. IE Doesn't care et, comme je l'ai découvert via this post, le RFC 2965 Specification exige que les implémenteurs fournissent un point leader.

Une autre lecture m'a conduit à l'article "Privacy alert: Cookie variants can be used to skirt blockers, anti-spyware tools". Essentiellement, de nombreux sites utilisent des sous-domaines comme un moyen de cacher les cookies de suivi.

Il ressemble à un logiciel anti-spyware respectera P3P (Platform for Privacy Preferences) déclarations sur le domaine parent. Malheureusement, en raison du manque de support des implémenteurs de navigateur, le travail a été suspendu sur P3P.

A ce stade, je pense que la solution au problème sera comme un utilisateur suggéré: le sous-domaine devra créer son propre cookie d'authentification.

Source

2010-02-16 aboy021

Je pense que le logiciel antispyware fonctionne comme annoncé. Envisagez de refactoriser les choses afin d'avoir un portail de connexion unique (par exemple, login.bar.com) qui redirige vers la ressource souhaitée après l'authentification. –

Je ne vois pas cela comme une programmation liée. –

En quoi cette programmation n'est-elle pas liée exactement? Il essaie de créer des cookies par programmation que les logiciels espions ne détecteront pas comme des menaces. –

Vous pouvez vérifier que votre cookie auth utilise le domaine .bar.com qui devrait fonctionner à www.bar.com, foo.bar.com, etc.bar.com.

Ce comportement exact est au navigateur, mais cela est la pratique courante pour permettre le même cookie sur plusieurs sous-domaines. Notez que si votre cookie d'origine a réglé www.bar.com à l'origine, alors un bon navigateur devrait le rejeter pour foo.bar.com mais pas pour

Ai-je un sens? :-)

Mise à jour: On dirait que vous pouvez remplacer le domain dans la section <forms de votre web.config, voici un link. Je commencerais là.

Source

2010-02-16 23:51:16

Je crains que nous n'utilisions actuellement _.bar.com_ en utilisant la technique décrite dans le lien utile que vous avez fourni. – aboy021

@ aboy021: J'avais peur de ça. Si tel est le cas, je ne suis pas sûr de ce que vous pouvez faire pour surmonter un logiciel anti-spyware qui choisit d'ignorer les normes. Vous pouvez essayer de dupliquer le cookie sur plusieurs domaines spécifiques, mais je suppose que l'anti-spyware se plaindra également que vous créez des cookies pour un domaine différent de celui auquel l'utilisateur accède actuellement. Bonne chance à comprendre. –

Vous pouvez examiner les transports par défaut dans les spécifications du protocole SSO SAML pour avoir plus d'idées. Archiver avec tous les documents est ici http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip regarder dans "Assertions et protocoles" pour la description du protocole et "Liaisons" pour les transports possibles (en particulier à la redirection et POST).

idée commune il est d'interroger en quelque sorte serveur SSO si l'utilisateur est authentifié en cours et mettre en cache ce statut avec propre cookie. De cette manière, chaque application ne place que des cookies sur son propre domaine.

Source

2010-02-17 08:20:55

Je pense que cette approche fonctionnera certainement. Pour l'instant, je vais voir si je peux obtenir le cookie sous une forme que le logiciel anti-spyware trouve acceptable. – aboy021

J'ai construit un système comme celui-ci. Il y a un domaine qui fait le login (site auth).Si la connexion est réussie, elle redirige l'utilisateur du site d'authentification vers le site qui a initié la connexion avec un token unique. Ensuite, ce site définit son propre cookie et bobs votre oncle. Lorsque vous vous déconnectez, vous devez vous rendre directement sur le site d'authentification qui supprime le cookie dans le cadre de la redirection vers le site. Votre site supprime ensuite son propre cookie. Hahaha espère que cela a du sens!

Source

2010-02-17 21:32:52 superlogical

Malheureusement, nous aimerions conserver la fonctionnalité de connexion unique, donc s'ils se connectent à 'bar.com', ils sont effectivement connectés à' foo.bar.com' et 'cat.bar.com'. Je pense qu'avec un jeton unique, nous perdrions cela. En fonction des tests que j'ai effectués, le cookie de domaine parent n'est supprimé que quelques secondes plus tard. Nous devrions donc pouvoir l'utiliser comme un jeton unique pour les utilisateurs concernés. – aboy021

.. Donc, votre connecté sur foo.bar.com. Vous allez à cat.bar.com le serveur remarque que vous n'êtes pas connecté au chat donc il vous redirige vers foo.bar.com qui sait que vous êtes connecté, donc génère un jeton et vous renvoie à cat.bar.com qui se connecte Si vous n'étiez pas connecté à foo.bar.com, il vous renvoie à chat avec un jeton différent en disant que vous n'êtes pas connecté alors n'essayez pas de m'authentifier automatiquement. Ça pourrait marcher? – superlogical

signe unique sur les cookies enlevé par un logiciel anti-spyware

Répondre

Questions connexes