Single sign on cookie rimosso dal software antispyware

Abbiamo un unico segno sull'implementazione per una famiglia di siti Web in cui il cookie di autenticazione proviene dal dominio principale (ad esempio bar.com), consentendo loro di accedere a un dominio figlio (es. foo.bar.com). L'implementazione è in C# utilizzando l'autenticazione standard .net.Single sign on cookie rimosso dal software antispyware

Sfortunatamente, alcuni dei nostri utenti stanno avendo i loro cookie di autenticazione cancellati dal software antispyware. Sono stato in grado di ricreare questa situazione utilizzando PC Tools Anti Spyware e IE8.

Il risultato pratico è che gli utenti accedono al sito, navigano verso un'altra pagina e poi gli chiedono di accedere di nuovo.

Il cookie è contrassegnato come cookie di tracciamento a basso rischio dal software antispyware.

C'è un modo per rendere il cookie più appetibile ai gusti apparentemente piuttosto pignoli del software antispyware dei nostri utenti?

Aggiornamento:

Ho esaminato il principale "" problema ed è una falsa pista. IE Doesn't care e, come ho scoperto tramite this post, lo RFC 2965 Specification richiede che gli implementatori forniscano un punto iniziale.

Ulteriori letture mi hanno portato all'articolo "Privacy alert: Cookie variants can be used to skirt blockers, anti-spyware tools". In sostanza, molti siti Web utilizzano i sottodomini in modo da nascondere i cookie di tracciamento.

Sembra che alcuni software anti-spyware rispettino le dichiarazioni P3P (Platform for Privacy Preferences) nel dominio padre. Sfortunatamente, a causa della mancanza di supporto da parte degli implementatori di browser, il lavoro è stato sospeso su P3P.

In questa fase penso che la soluzione al problema sarà come suggerito da un utente: il sottodominio dovrà creare il proprio cookie di autenticazione.

fonte

2010-02-16 aboy021

Penso che il software antispyware funzioni come pubblicizzato. Considerare il refactoring delle cose in modo da avere un portale di single signon (ad esempio, login.bar.com) che reindirizza alla risorsa desiderata dopo l'autenticazione. –

Non vedo questo come relativo alla programmazione. –

Com'è collegato esattamente questo problema? Sta cercando di creare cookie programmaticamente che lo spyware non rileverà come minacce. –

È possibile verificare che il proprio cookie di autenticazione stia utilizzando il dominio .bar.com che dovrebbe funzionare a www.bar.com, foo.bar.com, etc.bar.com.

Questo comportamento esatto dipende dal browser, ma questa è la pratica comune per consentire lo stesso cookie su più sottodomini. Nota che se il tuo auth cookie originariamente impostato www.bar.com allora un buon browser dovrebbe respingerlo per foo.bar.com ma non per foo.www.bar.com

Sto cercando di capire? :-)

Aggiornamento: Sembra che è possibile ignorare la domain nella sezione <forms del web.config, ecco una link. Vorrei iniziare da lì.

fonte

2010-02-16 23:51:16

Ho paura che stiamo attualmente utilizzando _.bar.com_ utilizzando la tecnica descritta nel link utile che hai fornito. – aboy021

@ aboy021: ne avevo paura. Se questo è il caso, non sono sicuro di cosa si possa fare per superare un software anti-spyware che sceglie di ignorare gli standard. Potresti provare a duplicare il cookie su più domini specifici, ma presumo che l'anti-spyware si lamenterà anche della creazione di cookie per un dominio diverso da quello a cui l'utente sta attualmente accedendo. Buona fortuna a capirlo. –

È possibile esaminare i trasporti predefiniti nelle specifiche del protocollo SSO SAML per avere più idee. Archiviare con tutti i documenti è qui http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip esaminare "Asserzioni e protocolli" per la descrizione del protocollo e "Associazioni" per i possibili trasporti (in particolare al reindirizzamento e al POST).

L'idea comune è quella di interrogare in qualche modo il server SSO se l'utente corrente è autenticato e quindi memorizzare tale stato nel proprio cookie. In questo modo ogni applicazione imposta solo i cookie sul proprio dominio.

fonte

2010-02-17 08:20:55

Penso che questo approccio funzionerà sicuramente. Per ora vedrò se riesco a ottenere il cookie in una forma che il software antispyware trova accettabile. – aboy021

Ho costruito un sistema come questo. C'è un dominio che fa il login (auth).Se l'accesso ha esito positivo, reindirizza l'utente dal sito auth al sito che ha avviato l'accesso con un token singolo. Quindi quel sito imposta il suo cookie e fa il broncio a tuo zio. Quando esci devi andare direttamente al sito auth che cancella il cookie come parte del reindirizzamento al sito. Il tuo sito elimina quindi il proprio cookie. Hahaha spero che abbia senso!

fonte

2010-02-17 21:32:52 superlogical

Sfortunatamente, vorremmo ancora mantenere la funzionalità di accesso singolo, quindi se accedono a 'bar.com' vengono effettivamente registrati in' foo.bar.com' e 'cat.bar.com'. Penso che con un gettone una volta lo perderemmo. In base ai test svolti, il cookie del dominio parent viene eliminato solo dopo alcuni secondi, quindi dovremmo essere in grado di utilizzarlo come token una tantum per gli utenti interessati. – aboy021

.. Quindi hai effettuato l'accesso a foo.bar.com. Vai su cat.bar.com il server si accorge che il tuo non è connesso a cat quindi ti reindirizza a foo.bar.com che sa di aver effettuato l'accesso in modo da generare un token e inviarti a cat.bar.com che registra in. Se non hai effettuato l'accesso a foo.bar.com, ti rimanda a cat con un token diverso dicendo che non hai effettuato l'accesso, quindi non provare e autenticarti automaticamente. Potrebbe funzionare? – superlogical

Single sign on cookie rimosso dal software antispyware

risposta

Problemi correlati