Single Sign on Cookie eliminado por software antispyware

Tenemos una implementación de inicio de sesión único para una familia de sitios web donde la cookie de autenticación proviene del dominio raíz (por ejemplo, bar.com), lo que les permite iniciar sesión en un dominio secundario (por ejemplo, foo.bar.com). La implementación está en C# utilizando la autenticación de formularios .net estándar.Single Sign on Cookie eliminado por software antispyware

Desafortunadamente, algunos de nuestros usuarios están teniendo sus cookies de autenticación eliminadas por el software anti spyware. Pude recrear esta situación utilizando PC Tools Anti Spyware e IE8.

El resultado práctico es que los usuarios inician sesión en el sitio, navegan a otra página y luego se les pide que inicien sesión de nuevo.

La cookie está marcada como una cookie de seguimiento de bajo riesgo por el software anti spyware.

¿Hay alguna manera de hacer que la cookie sea más apetecible para los gustos aparentemente más exigentes del software anti spyware de nuestro usuario?

Actualización:

He mirado en el principal "" problema y es una pista falsa. IE Doesn't care y, como me enteré por this post, el RFC 2965 Specification requiere que los implementadores suministren un punto inicial.

Lectura adicional me llevó al artículo "Privacy alert: Cookie variants can be used to skirt blockers, anti-spyware tools". Esencialmente, muchos sitios web están utilizando subdominios como una forma de ocultar las cookies de seguimiento.

Parece que algún software anti-spyware respetará las declaraciones P3P (Platform for Privacy Preferences) en el dominio principal. Desafortunadamente, debido a la falta de soporte de los implementadores del navegador, el trabajo se ha suspendido en P3P.

En esta etapa, creo que la solución al problema será como sugirió un usuario: el subdominio tendrá que crear su propia cookie de autenticación.

Fuente

2010-02-16 aboy021

Estoy pensando que el software antispyware está funcionando como se anuncia. Considere refaccionar las cosas para que tenga un portal de inicio de sesión único (por ejemplo, login.bar.com) que redirija al recurso deseado después de la autenticación. –

No veo esto como programación relacionada. –

¿Cómo no se relaciona esto exactamente con la programación? Está tratando de crear cookies programáticamente que el spyware no detectará como amenazas. –

Puede verificar que su cookie de autenticación esté utilizando el dominio .bar.com que debería funcionar en www.bar.com, foo.bar.com, etc.bar.com.

Este comportamiento exacto depende del navegador, pero esta es la práctica común de permitir la misma cookie en múltiples subdominios. Tenga en cuenta que si la cookie de autenticación originalmente establecido www.bar.com luego un buen navegador debe rechazar por foo.bar.com pero no para foo.www.bar.com

estoy haciendo ningún sentido? :-)

Actualización: parece que se puede anular el domain en la sección <forms de su Web.config, aquí hay un link. Yo comenzaría allí.

Fuente

2010-02-16 23:51:16

Me temo que actualmente estamos usando _.bar.com_ utilizando la técnica que se describe en el enlace útil que nos ha proporcionado. – aboy021

@ aboy021: tenía miedo de eso. Si este es el caso, entonces no estoy seguro de qué puede hacer para superar un software anti-spyware que elige ignorar los estándares. Podría intentar duplicar la cookie en múltiples dominios específicos, pero supongo que el anti-spyware también se quejará de que está creando cookies para un dominio diferente al que el usuario está accediendo actualmente. La mejor de las suertes al descubrir esto. –

Puede examinar los transportes predeterminados en las especificaciones del protocolo SAML SSO para tener más ideas. El archivo con todos los documentos está aquí http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip busque en "Afirmaciones y protocolos" para la descripción del protocolo y "Vinculaciones" para posibles transportes (en particular en redirección y POST).

Idea común de que hay que consultar de alguna manera el servidor SSO si el usuario actual está autenticado y luego almacenar ese estado en caché con su propia cookie. De esta forma, cada aplicación establece solo cookies en el dominio propio.

Fuente

2010-02-17 08:20:55

Creo que este enfoque ciertamente funcionará. Por ahora, voy a ver si puedo conseguir que la cookie esté en una forma que el software anti spyware encuentre aceptable. – aboy021

Creé un sistema como este. Hay un dominio que realiza el inicio de sesión (sitio de autenticación).Si el inicio de sesión es exitoso redirecciona al usuario del sitio de autenticación al sitio que inició el inicio de sesión con un token único. Entonces ese sitio establece su propia cookie y mueve a su tío. Cuando finaliza la sesión, debe ir directamente al sitio de autenticación, que borra la cookie como parte de la redirección al sitio. Su sitio luego elimina su propia cookie. Jajaja espero que tenga sentido!

Fuente

2010-02-17 21:32:52 superlogical

Desafortunadamente, aún nos gustaría mantener la capacidad de inicio de sesión único, por lo que si inician sesión en 'bar.com', están efectivamente conectados a' foo.bar.com' y 'cat.bar.com'. Creo que con un token de una vez perderíamos eso. Según las pruebas que he estado haciendo, la cookie del dominio principal solo se elimina después de unos segundos, por lo que deberíamos poder usar esto como un token de una sola vez para los usuarios afectados. – aboy021

.. Por lo tanto, has iniciado sesión en foo.bar.com. Vaya a cat.bar.com, el servidor se da cuenta de que no ha iniciado sesión en cat, por lo que lo redirige a foo.bar.com, que sabe que está conectado, por lo que genera un token y lo envía de vuelta a cat.bar.com, que registra si no estuviste conectado a foo.bar.com, te envía de vuelta a cat con un token diferente que dice que no has iniciado sesión, así que no intentes autenticarme automáticamente. ¿Eso podría funcionar? – superlogical

Single Sign on Cookie eliminado por software antispyware

Respuesta

Cuestiones relacionadas