Mientras trabajaba con la autenticación de formularios ASP.Net, encontré la cookie .ASPXAUTH. Tengo un par de preguntas:
- ¿Cuál es el propósito de esta cookie?
- ¿Cuál es la ubicación de esta cookie?
¿Qué es la cookie ASPXAUTH?
Respuestas:
La cookie ASPXAUTH se utiliza para determinar si un usuario está autenticado.
En cuanto a la ubicación de la cookie, eso depende de su navegador. Si está utilizando Firefox, puede ver la cookie haciendo clic en Herramientas -> Opciones -> Privacidad. Luego, desplácese hacia abajo hasta el dominio y expándalo para ver la cookie y su valor. El valor se cifra con la clave de la máquina (ubicada en el archivo machine.config o web.config del servidor), por lo que mirar la cookie en el cliente no le proporcionará realmente ninguna información. Puede descifrar / ver el valor en el lado del servidor usando:
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
donde authTickettiene estos campos:
La declaración "ASPXAUTH se utiliza básicamente para mantener el estado de sesión de ASP.NET" es incorrecta. ASP.NET emite una cookie completamente diferente, denominada ASP.NET_SessionId, para rastrear el estado de la sesión.
2
En Firefox v8.0, las cookies se pueden encontrar de la siguiente manera: Herramientas -> Información de la página -> Seguridad -> Ver cookies
—
Anthony
En la misma pestaña de seguridad hay un botón "Ver contraseñas guardadas" y, para mi sorpresa, pude ver todas las contraseñas como texto sin formato para varios sitios web que estaba navegando usando Firefox. Aunque el navegador debe almacenarlo en un formato codificado en el disco y solo se muestra para su referencia al decodificarlo, esta opción es realmente una amenaza para la seguridad por mucho que pueda pensar. Si cualquier pirata informático puede emplear el mismo algoritmo y leer esas cookies usando javascript, aunque la fuga de ese algoritmo es una posibilidad lejana, ya que podría estar involucrada con alguna clave que solo el código del navegador conoce.
—
RBT
Para obtener el nombre de la clave utilizada para almacenar la identificación de sesión de asp.net en la colección de cookies de la solicitud http, aquí está el código C #: var aspNetSessionState = new System.Web.Configuration.SessionStateSection (); var aspNetSessionCookieName = aspNetSessionState.CookieName;
—
RBT
En
—
Kiquenet
Application_PostAuthenticateRequestel Request.IsAuthenticated es cierto, pero .ASPXAUTH no el valor en mi HttpContext.Current.Request.Cookies. Yo uso sessionState.
Creé un proyecto MVC, ejecútelo. Registre la cuenta y luego inicie sesión. E inspeccione las cookies en la herramienta de desarrollo de Chrome, había un Aspnet.ApplicationCookie. Y luego agregó una línea en la acción de inicio de sesión: FormsAuthentication.SetAuthCookie (model.Email, true); y de nuevo inicie sesión e inspeccionó las cookies en la herramienta de desarrollo de Chrome, esta vez obviamente fue ASPXAuth. Entonces, ¿cuál es la diferencia en ambos?
En realidad, la cookie .ASPXAUTH no le dice con precisión cuándo el usuario está realmente autenticado. Cuando el usuario cierra la sesión de la aplicación, la cookie .ASPXAUTH se elimina del navegador. Sin embargo, si regresa al sitio dentro de un período corto de tiempo (con el tiempo de espera de la cookie de autenticación del formulario) y edita la nueva cookie ASP.NET_SessionId con lo siguiente:
- cambiar el campo "nombre" de "ASP.NET_SessionId" a ".ASPXAUTH"
- cambiar "valor" de sessionID de 24 caracteres a la antigua cadena de autenticación de 448 caracteres
Después de la actualización, podrá asumir la identidad del usuario autenticado sin necesidad de volver a autenticarse técnicamente. (nuevamente asumiendo que hace esto dentro del tiempo de espera específico almacenado dentro de la cadena de autenticación cifrada .ASPXAUTH)
Una buena publicación de blog explica el problema con más detalle. Una posible solución es acoplar el .ASPXAUTH con la sesión ASP.
Si las interacciones de un usuario con la URL de inicio de sesión HTML han permitido que TSWPPserver establezca la identidad del usuario, el servidor remoto DEBE generar una cookie que identifica al usuario y permite la autenticación en el servidor. El contenido de la cookie DEBE estar firmado y cifrado. La implementación específica de esta cookie, incluidos los algoritmos de firma y cifrado, depende de la implementación del servidor TSWPP, porque solo se requiere que el servidor analice el contenido de la cookie. Si el servidor implementa la cookie, la cookie DEBE devolverse en una carga útil HTTP con un tipo de contenido de "application / x-msts-webfeed-login".