with visual tutorial studio started route net mvc getting descargar data asp all asp.net security cookies ssl same-origin-policy

visual - ¿Cómo se puede proteger ASP.NET o ASP.NET MVC de ataques de cookies de dominio relacionados?



getting started with asp net (9)

Fuente: http://www.w2spconf.com/2011/papers/session-integrity.pdf Conferencia de Seguridad y Privacidad de la Web 2.0

.

6. Integridad de sesión en navegadores futuros Ninguna de las soluciones anteriores, ni otras que consideraron el uso de tecnologías de navegadores existentes, brindan la seguridad suficiente mientras permanecen desplegables para sitios existentes. Por lo tanto, proponemos una extensión a las cookies llamadas cookies de origen. Las cookies de origen permiten que las aplicaciones web existentes se protejan contra los ataques descritos, con muy poca complejidad de implementación por parte de la aplicación web o el navegador, con compatibilidad retroactiva transparente para los navegadores que aún no implementan cookies de origen, incluidos los navegadores heredados que puede que nunca los respalde ni imponga ninguna carga a los sitios web existentes que no hayan habilitado las cookies de origen. Este no es un problema trivial para resolver, como lo demuestran las propuestas existentes que no cumplen con una o más de las propiedades deseadas anteriormente. Por ejemplo, enviar el origen de cada cookie en cada solicitud es una idea común. Esto es mucho más complicado de lo necesario e impone una carga mucho mayor en los sitios web, incluidos los que ni siquiera saben cómo utilizar esta información de manera efectiva.

6.1. Cookies de origen El problema real con el uso de cookies para la gestión de sesiones es la falta de integridad, específicamente debido a la capacidad de otros orígenes para borrar y sobrescribir las cookies. Si bien no podemos deshabilitar esta funcionalidad de las cookies sin romper muchos sitios existentes, podemos introducir nuevas funcionalidades tipo cookie que no permiten dicha modificación entre sitios.

Diseño. Las cookies de origen son cookies que solo se envían y solo se pueden modificar mediante solicitudes y respuestas de un origen exacto. Se configuran en respuestas HTTP de la misma manera que las cookies existentes (usando el encabezado Set-Cookie), pero con un nuevo atributo llamado ''Origen''. Para permitir que las aplicaciones web distingan las cookies de origen de las cookies normales, las cookies de origen se enviarán en una solicitud HTTP en un nuevo encabezado ''OriginCookie'', mientras que las cookies normales continuarán siendo enviadas en el encabezado existente ''Cookie''.

HTTP/1.1 200 OK ... Set-Cookie: foo=bar; Origin ... Fig. 2. An HTTP response setting an origin cookie. GET / HTTP/1.1 Host: www.example.com ... Origin-Cookie: foo=bar ...

Fig. 3. Una solicitud HTTP a un URI para el cual se ha establecido una cookie de origen.

Por ejemplo, si en respuesta a una solicitud GET para http://www.example.com/ , se recibe una respuesta como en la Figura 2, entonces se establecería una cookie de origen con la clave ''foo'' y el valor ''bar'' para el origen http://www.example.com/ , y se enviaría en solicitudes posteriores a ese origen. Una solicitud GET subsiguiente para http://www.example.com/ se vería como en la Figura 3. Las solicitudes hechas a cualquier otro origen, incluso https://www.example.com y http://example.com se realizarían exactamente como si nunca se hubiera establecido la cookie de origen para http://www.example.com/ . El atributo Origin que extiende la semántica de Set-Cookie en sí mismo es sutil e implica varios cambios semánticos a otros atributos configurables de las cookies. Si se establece el atributo Origin, el atributo Domain ya no es apropiado y, por lo tanto, debe ignorarse. Del mismo modo, el atributo Secure ya no es apropiado, ya que está implícito en el esquema del origen de la cookie: si el esquema es https, la cookie de origen tiene efectivamente el atributo, ya que solo se enviará a través de un canal seguro. y si el esquema es otra cosa, la cookie no tiene el atributo. Debido a que la política del mismo origen considera que las diferentes rutas forman parte del mismo origen, el atributo Ruta de las cookies no brinda seguridad y también debe ignorarse. La semántica de otros atributos, como HttpOnly , Max-Age , Expires , etc. no cambian para las cookies de origen. Las cookies normales se identifican de forma única por su clave, el valor del atributo de Dominio y el valor del atributo Ruta: esto significa que al establecer una cookie con una clave, Dominio y Ruta que ya está configurada no se agrega una nueva cookie, pero en su lugar reemplaza esa cookie existente. Las cookies de origen deben ocupar un espacio de nombre separado, y deben ser identificadas de manera única por su clave y el origen completo que la establece. Esto evita que los sitios eliminen accidental o maliciosamente las cookies de origen, además de las otras protecciones contra la lectura y modificación, y hace que el uso de cookies de origen del lado del servidor sea significativamente más fácil.

Seguridad. Debido a que las cookies de origen están aisladas entre orígenes, las facultades adicionales del atacante del dominio relacionado y del atacante de red activo al sobreescribir cookies ya no son efectivas, ya que explotaban específicamente la falta de aislamiento del origen con las cookies existentes, independientemente de si la "confusión" al esquema o dominio del origen. En ausencia de estos poderes adicionales, el atacante del dominio relacionado y el atacante activo de la red son equivalentes al atacante web, que no puede violar la seguridad de la gestión de sesión existente en función de la combinación de cookies y tokens secretos.

Implementación. La integración de las cookies de origen en los navegadores existentes no implicará modificaciones significativas. Como una prueba de concepto, implementamos cookies de origen en Chrome. El parche tiene un total de 573 líneas

El ataque de cookie de dominio relacionado (más información) permite que las máquinas en el mismo dominio DNS agreguen cookies adicionales que también se enviarán a otras computadoras en el mismo dominio.

Esto puede causar problemas con la autenticación o, en el peor de los casos, ser un componente en un ataque adjunto confuso.

Pregunta

¿Cómo puedo proteger ASP.NET o ASP.NET MVC de este tipo de ataque?

Un posible escenario de ataque

  1. Me conecto a una aplicación web "segura"
  2. Obtengo las credenciales para mi cuenta
  3. Yo engaño al usuario para que visite mi sitio en el mismo dominio DNS
  4. Inserto la cookie (de mis creds)
  5. el usuario vuelve a su aplicación.
  6. Ambas cookies (o una sobrescrita) se envían al servidor
  7. El usuario está haciendo cosas en mi cuenta

Ese es un ejemplo simplificado, pero la idea puede trasladarse a otro estilo de ataque, solo estoy escogiendo el escenario que no parece "demasiado malo".

Una idea de cómo puede "ponerse mal" es si este fue el paso 1 de un ataque de dos pasos. Supongamos que el usuario ha subido un archivo incorrecto al que solo se puede acceder desde su cuenta; el otro usuario luego inconscientemente descarga ese archivo, ejecutando cualquier código ejecutable que esté allí.

Hay un montón de otros escenarios que son posibles ... en lugar de enumerarlos aquí. Estoy tratando de descubrir cómo puedo proteger mi servidor de este tipo de ataque.

Procedencia de: http://www.w2spconf.com/2011/papers/session-integrity.pdf

5.2. Integridad a través de encabezados personalizados

En lugar de asegurar las cookies, podemos lograr la integridad de la sesión eligiendo un nuevo método para almacenar y transmitir el estado de la sesión. Si bien esto podría hacerse utilizando complementos especiales del navegador como Flash, preferiríamos elegir un diseño con la menor cantidad de dependencias, por lo que solo nos enfocaremos en las herramientas HTTP básicas. La forma básica de una solicitud HTTP tiene muy pocos lugares que sean adecuados para enviar datos con integridad. Los datos en el URL o en el cuerpo de la entidad de las solicitudes HTTP no tienen integridad, porque esas partes de la solicitud HTTP se pueden escribir en todos los orígenes y, por lo tanto, pueden ser falsificadas por un atacante. Las cookies también son débiles en este sentido, ya que pueden ser sobrescritas por el atacante en nuestro modelo de amenaza. Sin embargo, mediante el uso de una API de JavaScript llamada XMLHttpRequest (XHR), podemos enviar datos en un encabezado personalizado.

Fondo. XMLHttpRequest (XHR) permite realizar solicitudes HTTP que contienen encabezados personalizados y leer las respuestas, pero solo al origen del JavaScript de ejecución. (Ver Nota 5) Como resultado, las solicitudes hechas a través de XHR pueden distinguirse por un servidor como necesariamente originario del sitio en sí.

Diseño. No utilizaremos cookies en absoluto, y en su lugar transferiremos un token de identificación de sesión en un encabezado HTTP personalizado que solo se escribe a través de XMLHttpRequest. El servidor debe tratar todas las solicitudes que carecen de este encabezado personalizado, o que contienen un token no válido, como pertenecientes a una nueva sesión anónima. Para poder conservar esta sesión identificando el token en los reinicios del navegador y entre las diferentes páginas de la misma aplicación, el token se puede almacenar en HTML5 localStorage mediante JavaScript luego de una autenticación exitosa.

Seguridad. Observe que en este modelo, el token de identificación de la sesión solo se enviará al servidor de origen y no se incluirá en la URL ni en el cuerpo de la entidad. Estas propiedades proporcionan con fi dencialidad e integridad, respectivamente. A diferencia de las cookies, el atacante no puede sobrescribir el token, ya que localStorage divide por completo los datos entre los orígenes en la mayoría de los navegadores (ver Nota 6). Un sitio que use HTTPS puede garantizar que el token solo se envíe a través de HTTPS, lo que garantiza el secreto del token incluso en presencia de un atacante de red activo. Además, dado que este token no es enviado automáticamente por el navegador, también sirve para proteger contra los ataques CSRF.

Desventajas Este enfoque, sin embargo, tiene varias desventajas. En primer lugar, requiere que todas las solicitudes que requieren acceso a la sesión de un usuario se realicen mediante XMLHttpRequest. Simplemente agregar un token de identificación de sesión explícitamente a todas las solicitudes, mucho menos hacerlas a través de XHR, requeriría cambios importantes en la mayoría de los sitios web existentes, y sería engorroso y difícil de implementar correctamente sin un marco. Esto es aún más complicado si las solicitudes de sub-recursos como imágenes requieren acceso al estado de la sesión, ya que no es trivial cargar imágenes a través de XHR. En tercer lugar, dado que este diseño depende de la presencia y seguridad de HTML5 localStorage, será imposible implementarlo en algunos navegadores heredados.

(Nota 5) Los sitios pueden realizar solicitudes entre sitios utilizando XHR si el navegador lo admite y el servidor de destino lo autoriza.

(Nota 6) Es cierto en Chrome, Firefox, Safari y Opera en OS X, varias distribuciones de Linux y Windows 7. Internet Explorer 8 no realiza particiones HTTP y HTTPS, pero Internet Explorer 9 sí.

Fuente: Listas de correo del W3C

TLS-OBC , por lo que siempre que la clave privada correspondiente al TLS-OBC esté solo en una máquina, la cookie solo se puede usar en una máquina.

Si desea emular el enfoque de certificación de cliente TLS, puede usar localStorage para almacenar una clave privada y usar JS crypto 1 para reemplazar document.cookie con una versión firmada. Es un poco torpe, pero podría funcionar. (Obviamente, sería mejor con web crypto TLS-OBC )

1 por ejemplo: http://www.ohdave.com/rsa/

TLS-OBC http://www.w3.org/community/webcryptoapi/

Puntos principales

  1. No dar permiso para ejecutar en los directorios de carga (un atacante puede ser desde adentro).
  2. Obtenga toda la información de usuario posible que se conecte al servidor (la cookie es solo una).
  3. Controle el servidor y las alertas (lo encuentre / lo vea, deténgalo, cierre la puerta).

Respuesta para

Supongamos que el usuario ha subido un archivo incorrecto al que solo se puede acceder desde su cuenta; el otro usuario luego inconscientemente descarga ese archivo, ejecutando cualquier código ejecutable que esté allí.

En primer lugar, no debe permitir que se ejecute nada en sus directorios cargados, porque incluso sus usuarios habituales pueden cargar una página aspx y ejecutarla y examinar sus archivos. El primer paso para esto es agregar a sus directorios de carga este web.config (pero también establecer los permisos para no permitir que se ejecute nada).

<configuration> <system.web> <authorization> <deny users="*" /> </authorization> </system.web> </configuration>

relativo: me han pirateado. Evil aspx archivo cargado llamado AspxSpy. Aún lo están intentando. ¡Ayúdame a atraparlos!

Robando las galletas

Veamos cómo podemos identificar al usuario.

  1. Galleta
  2. ID del navegador
  3. Ip incluyendo proxy y forward ips.
  4. El navegador tiene javascript enable (o no).
  5. Solicitud directa de contraseña
  6. Otro archivo almacenado en el cliente.

Ahora, por cada sesión que haya iniciado sesión, podemos conectar las primeras cuatro informaciones, y si alguna de ellas cambia, podemos desconectarlo y volver a solicitar que inicie sesión.

También es fundamental conectar de alguna manera (con una línea en la base de datos) la cookie con el estado de inicio de sesión del usuario, por lo que si el usuario cierra sesión, no importa si alguien roba su cookie, no para poder ver las páginas: lo que quiero decir es que la cookie que le permitió iniciar sesión no debe ser la única en la que confiamos, sino también nuestros datos para rastrear el estado del usuario.

En este caso, incluso si algunos roban la cookie, si el usuario cierra sesión después de algunas acciones, la cookie ya no es útil.

Entonces, lo que hacemos es conectar la cookie + ip + browser id + javascript information por inicio de sesión, y si alguno de ellos cambia, no confiamos más en él, hasta que inicie sesión de nuevo.

Galletas

Una cookie no es suficiente. Necesitamos al menos dos cookies, una que funcione solo en páginas seguras, y se requiere que sea https segura y una que funcione en todas las páginas. Estas dos cookies deben estar conectadas juntas y esta conexión también debe mantenerse en el servidor.

Entonces, si una de estas cookies no existe, o la conexión no coincide, entonces el usuario nuevamente no tiene permiso y necesita iniciar sesión de nuevo (con una alerta para nosotros)

relativo: ¿Puede algún hacker robar la cookie de un usuario e iniciar sesión con ese nombre en un sitio web?

Una idea para conectar las cookies juntas . Con esta idea, conecto la cookie de sesión con la cookie de autenticación.

Si todo falla

Hay algunos pasos (o acciones) que un pirata informático sigue (hace) al llegar a un sitio para poder aprovechar esta oportunidad de ventana y dejar abierta una puerta trasera.

  1. Crea una nueva cuenta de administrador.
  2. Suba un archivo para ejecutarlo como navegador y ejecutable.

Como digo, nunca permitimos que se pueda cargar un archivo que se puede ejecutar, así que esto es fácil. La otra para crear una nueva cuenta de administrador es la que necesitamos para agregar una contraseña adicional que no se guarda en ninguna cookie, o que exista de todos modos en el cliente.

Por lo tanto, para acciones raras como, Nuevo usuario de backoffice, cambiar el privilegio de los usuarios, eliminar un usuario, etc., debemos solicitar una segunda contraseña cada vez que solo el administrador lo sepa.

Entonces, la segunda contraseña es el último mes.

Una idea final

Una idea que no he hecho es almacenar cómo la información en el cliente que no sea la cookie, no se puede robar como las cookies, o incluso si se puede robar está oculta en algún lugar de todos los datos que es imposible de encontrar eso.

Esta información puede ser una identificación adicional del usuario junto con la cookie, datos del navegador, IP.

Estoy seguro de que hay algunos lugares posibles pero no los he probado ni probado en la vida real. Entonces esto es algo colocado.

  1. La extensión personalizada, o el complemento, desafortunadamente es diferente para cada navegador que tiene la capacidad de guardar datos y luego podemos usarlos para comunicarnos con el servidor. Esta es una acción requerida por el usuario para instalar este complemento, y para los usuarios habituales, esto puede hacer que tenga miedo y se vaya.
  2. Código oculto dentro de una buena imagen en caché, en el encabezado del mismo, por ejemplo, en etag. Esto también es fácil de no trabajar porque no podemos estar seguros de que la imagen solicite volver a cargar ...
  3. Algunas otras capacidades del navegador, por ejemplo, para leer y usar un certificado de cliente, que se pueden usar para intercambiar datos cifrados con el servidor. Esto solicita acción del usuario para instalar este certificado, y de nuestra parte para crearlos diferentes para cada usuario. Bueno para cuentas bancarias pero no para usuarios simples.

Así que estas son mis ideas ... cualquier crítica, o una solución (sobre cómo almacenar información pequeña en el cliente que no sea la cookie) es bienvenida.

Implementación

Para que sea realmente seguro, debemos hacer un seguimiento del usuario en el servidor y en la base de datos. Una tabla que conecta al usuario, con la ip, con la identificación del navegador y otro estado, como si ahora está conectado o no, es una medida que podemos usar para tomar decisiones.

Si no puede usar una base de datos, o no quiere dificultarlo, entonces la conexión puede estar intercambiando algunos datos y verificar si este hash es el mismo.

Por ejemplo, podemos establecer una cookie con el hash de (Ip + BrowserID) y comprobar si esto es mucho o no.

Alertas - Registro

Todo lo anterior intentan automatizar. Siempre sugiero que muestre al usuario y al administrador cierta información para diagnosticar y prevenir un ataque. Esta información puede ser

Para el usuario

  • Últimos 10 datos de inicio de sesión (IP, DateTime, Success or not)
  • Envíe un correo electrónico al usuario sobre algunas acciones (para sitios de alta seguridad), como inicio de sesión, cierre de sesión, acciones críticas.

Para el administrador.

  • Inicie sesión y muestre cualquier falla de la conexión en los cuatro parámetros Cookie + IP + BroserID + Habilitar Javascript). Cuanto más falle en poco tiempo, más atención se requiere.
  • Verifique el inicio de sesión fallido.
  • Compruebe la página leída del usuario sin la habilitación de cookies (o guardar) y javascript está deshabilitado, porque así es como se identificó el escáner según mi experiencia.

Desde http://www.codeproject.com/Articles/16645/ASP-NET-machineKey-Generator

Whenever you make use of ViewState, Session, Forms authentication, or other encrypted and/or secured values, ASP.NET uses a set of keys to do the encryption and decryption. Normally, these keys are hidden and automatically generated by ASP.NET every time your application recycles

If the two websites are different web applications, by default they will have different keys so one will not be able to read encrypted tokens generated by the other. The exception to this is if they are using common values in a global web.config or machine.config.

From machineKey Element, decryptionKey: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx

AutoGenerate, IsolateApps Specifies that the key is automatically generated. This is the default value. The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA). The IsolateApps modifier specifies that ASP.NET generates a unique encrypted key for each application using the application ID of each application.

So unless the machineKey element is being used to set the decryptionKey at a global level, the method you described should not work. If it is set, you could override at application level using the web.config file.

Channel Bound Cookies

El siguiente RFC propuesto proviene de un empleado de Google y describe una manera para que los Clientes usen un Certificado de navegador autofirmado (por lo que no requiere una "ventana emergente" confusa para el usuario final) que también puede abordar el problema de seguridad de cookies conocido como "Dominio relacionado". Galletas"

Lo que sigue a continuación es un extracto de http://www.browserauth.net/ , una sección de la RFC, algunos comentarios interesantes y algunas críticas sobre esta extensión.

Descripción general de Channel Bound Cookies

Una vez que el canal TLS subyacente usa autenticación de cliente TLS (con la extensión TLS-OBC), el servidor puede vincular sus cookies al canal TLS al asociarlas con la clave pública del cliente y asegurarse de que las cookies solo se usan sobre canales TLS autenticados. con esa clave pública (cliente).

Esto significa que si una cookie vinculada a un canal se roba alguna vez de la máquina de un cliente, esa cookie no podrá autenticar una sesión HTTP al servidor desde otras máquinas. Esto incluye atacantes intermediarios que se inyectan a sí mismos en la conexión entre el cliente y el servidor, quizás engañando a los usuarios para que hagan clic en advertencias de incompatibilidad de certificados: un hombre en el medio tendrá que generar su propia sesión TLS con el servidor, que no coincidirá con el canal al que está vinculada la cookie.

Enlace de canal

Depende del servidor decidir si vincula las cookies a los canales TLS. Si el cliente no es compatible con TLS-OBC , o si la cookie que está a punto de establecer se usará en diferentes origins , entonces el servidor no enlazará el canal con la cookie. Si decide vincular el canal a la cookie, debe asociar la cookie con la clave pública del cliente. Esto es similar al RFC 5929, pero en lugar de los datos de enlace del cliente a la clave pública del servidor, en este caso el servidor estaría vinculando los datos (la cookie) a la clave pública del cliente. El servidor puede hacer esto simplemente almacenando, en una base de datos back-end, el hecho de que se espera que cierta sesión HTTP sea autenticada con una clave pública de cliente determinada, o puede usar una criptografía adecuada para codificar en la cookie que el cliente TLS público la clave a la que está sujeta la cookie.

En la figura anterior, el servidor incluye la clave pública del cliente en una estructura de datos firmada criptográficamente que también incluye la identificación del usuario autenticado. Cuando el servidor recibe la cookie del cliente, puede verificar que efectivamente emitió la cookie (verificando la firma en la cookie) y verificar que la cookie se envió a través del canal correcto (al hacer coincidir la clave de cliente TLS con el clave mencionada en la cookie).

Continuará aquí .... http://www.browserauth.net/channel-bound-cookies

RFC Snip

TLS-OBC

(Extracto)

4.3. Endurecimiento de cookies

Una manera en que TLS-OBC se puede usar para fortalecer la autenticación basada en cookies es mediante el "enlace" de cookies a un certificado de origen. El servidor, al emitir una cookie para una sesión HTTP, asociaría el certificado de origen del cliente con la sesión (ya sea codificando la información sobre el certificado de forma impensable en la cookie o asociando el certificado con la sesión de la cookie a través de otros medios) . De esta forma, si una cookie se roba de un cliente, no se puede usar a través de una conexión TLS iniciada por un cliente diferente; el ladrón de cookies también tendría que robar la clave privada asociada con el certificado de origen del cliente, una tarea considerablemente más difícil, especialmente cuando asumimos la existencia de un Módulo de Plataforma Confiable u otro Elemento Seguro que puede almacenar el
clave privada del certificado con origen en origen.

Comentarios adicionales de [email protected]

Además, tenga en cuenta que, de manera un tanto intuitiva, las cookies vinculadas al canal protegen contra muchos ataques de dominio relacionado incluso si el cliente certifica que tienen un alcance más amplio que un origen web.

Imagine, por un momento, que un usuario-agente crea un solo certificado autofirmado que utiliza como un certificado de cliente TLS para todas las conexiones a todos los servidores (no es una buena idea en términos de privacidad, pero sígame para este experimento mental) ) Luego, los servidores configuran las cookies en sus respectivos dominios de nivel superior, pero los vinculan por canal al certificado de cliente único y del agente de usuario.

Entonces, digamos que una aplicación app.heroku.com establece una cookie (vinculada a un canal) en mi navegador para el dominio .heroku.com, y que hay un atacante en attacker.heroku.com. Un ataque del que podríamos estar preocupados es que el atacante simplemente recolecta la cookie .heroku.com de mi navegador atrayéndome a atacante.heroku.com. Sin embargo, no podrán usar la cookie porque la cookie está vinculada al canal del certificado del cliente de mi navegador, no al certificado del cliente del atacante.

Otro ataque del que podríamos estar preocupados es que atacante.heroku.com establece una cookie .heroku.com en mi agente de usuario para hacer que inicie sesión en app.heroku.com como él mismo. Nuevamente, suponiendo que la única forma en que el atacante puede obtener las cookies es obteniéndolas de app.heroku.com, esto significa que las cookies que tiene a su disposición estarán ligadas a su certificado de cliente, no a mi certificado de cliente. por lo tanto, cuando mi navegador los envíe a app.heroku.com, no serán válidos.

La propuesta de TLS-OBC, por supuesto, asume "ámbitos" más precisos para los certificados del cliente. La razón para eso, sin embargo, es puramente para evitar el seguimiento a través de dominios no relacionados. Los ataques de dominio relacionado ya se han mitigado incluso si usamos certificados de cliente de grano grueso y cookies de grano grueso (es decir, de dominio). Yo, al menos, encontré esto un poco contraintuitivo al principio, ya que el otro propuso defenderlo para prohibir por completo las cookies de grano grueso y usar cookies de origen en su lugar.

Crítica de [email protected]

Hay una serie de cuestiones que deben tenerse en cuenta para TLS-OBC; Destacaré un par de personas de las que tengo conocimiento.

  1. Es posible que deba modificarse ligeramente cierta lógica de protocolo de enlace SSL; ver https://bugzilla.mozilla.org/show_bug.cgi?id=681839 para una discusión técnica.

  2. Hay posibles consideraciones de privacidad; en particular, si el certificado único del cliente se envía en texto sin formato antes de la negociación del secreto principal, un observador de red pasivo puede identificar de manera única una máquina cliente. El atacante ya tendría la dirección IP del cliente, por lo que este no es un gran problema si el certificado se regenera en un cambio de dirección IP, pero eso anularía gran parte del beneficio de autenticación. Una propuesta para permitir que se envíe un certificado de cliente después de que se haya realizado la negociación secreta maestra. (No puedo encontrar el error en este momento, lo siento)

  3. Una propuesta sobre cómo podría abordarse el n. ° 2 está aquí: http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts

  4. Hay interacciones complicadas con SPDY. Habrá actualizaciones en browserauth.net para esto.

Repare los RFCs

El problema central aquí parece ser que cualquier host puede escribir una cookie que pueda ser sobrescrita por cualquier otro host en el mismo dominio. ¿Qué pasa si hay una forma de escribir un valor para el cliente que ningún otro host pueda sobrescribir? No he encontrado nada como eso también se incluye automáticamente en el encabezado HTTP (como una cookie)

Aquí hay tres soluciones que podrían funcionar, aunque me gustan las soluciones 2 o 3 si los navegadores lo implementan correctamente

Solución 1: agregue más información al cargar cookies en el servidor

Cuando el cliente envía cookies al servidor, también incluye el dominio de la cookie que se envió. El servidor sabe qué dominio y ruta buscar. Esto significa que el cliente agrega un nuevo encabezado HTTP Cookie-Details en cada solicitud:

GET /spec.html HTTP/1.1 Host: www.example.org Cookie: name=value; name2=value2 Cookie-Details: name="value":"domain":"path":"IsSecure":"IsHTTPOnly"; name2="value2":"domain2":"path2":"IsSecure":"IsHTTPOnly" Accept: */*

El servidor puede entonces ignorar el campo de detalles, o preferirlo sobre el que no proporciona los detalles. La razón por la que incluí el campo "valor" en la sección de detalles es porque el servidor no podría distinguir entre dos cookies que tienen el dominio establecido en example.com y secure.example.com si ambas cookies tienen el mismo nombre. La mayoría de los navegadores enviarán los valores en orden aleatorio.

Quizás esto se puede optimizar para que el servidor pueda decirle al cliente si este nuevo formato de cookie es compatible o no, y el cliente puede responder en consecuencia.

Solución 2: Extienda HTML5 LocalStorage para que los datos (opcionalmente) se inserten automáticamente en el encabezado HTTP

Si pudiéramos ampliar LocalStorage de HTML5 para permitir datos seguros / HTTPOnly, podemos imitar lo que se hace en la Solución n. ° 1 anterior, pero hacer que el cambio sea impulsado por el grupo de trabajo LocalStorage W3C de HTML5.

El beneficio de esto es que hay menos sobrecarga que la solución n. ° 1, ya que los detalles más detallados de las cookies solo se envían al servidor cuando es necesario. En otras palabras, si se guarda un valor confidencial utilizando el formato "nuevos detalles de la cookie" en LocalStorage, entonces existe una clara separación de qué datos se deben enviar y en qué formato.

Solución 3 "Validación de cookies"

  1. Un usuario visita una aplicación web que tiene habilitado este modo de validación "especial".
  2. En la respuesta HTTP, algunas cookies se envían al navegador. Las cookies pueden ser solo HTTP, seguras, ... cualquier cosa)
  3. A junto a las cookies, se envía otro encabezado a las cookies: Set-CookieValidationHash . Contiene una matriz JSON de claves y valores de cookie hash SHA-256 y especifica la caducidad del valor
  4. El navegador luego vincula lógicamente este encabezado a las cookies con el siguiente comportamiento
    • Este encabezado se coloca en un "Frasco de validación de cookies" que solo puede ser escrito por el mismo Dominio DNS y el Alcance de DNS.
  5. Este encabezado es opaco para el cliente y se devuelve al servidor en cada solicitud HTTP (como una cookie)
  6. El servidor usará este campo para validar las cookies que se envían y emitirá un error (o lo que sea) si falla la suma de comprobación.

The answer is simple: Always bind sessions to a specific client IP (this should be done in any modern web application anyway) and do not use cookies for any other purpose.

Explanation: you always send a single SESSIONID cookie back to the client, which holds no information - its just a very long random string. You store the SESSIONID along with the authenticated user IP within your webapps scope - like ie the database. Although the related cookie attack can be used to swap SESSIONID cookies around between different clients, no client can ever masquerade as another user or perform any actions, as the SESSIONID is only considered valid and the privileges are only granted, if its send from the associated IP address.

As long as you do not store actual data which is considered private into the cookie itself, but into the session state on the server side (which is selected solely by the SESSIONID cookie) the related cookie problem should be no problem for you.

You could set a unique machineKey in the web.config for your application. This way only authentication cookies emitted by that application can be decrypted. If the user visits a malicious site on the same domain, this other site might indeed add an cookie authentication cookie with the same name but different value, but it won''t be able to encrypt and sign it with the same machine key used by your application and when the user navigates back an exception will be thrown.