Protegiéndose contra ataques de cookies entre subdominios

21

He estado leyendo sobre ataques de cookies entre subdominios aquí .

Una visión general rápida de cómo funciona (de Wikipedia):

  1. Un sitio web www.example.com reparte subdominios a terceros no confiables
  2. Una de esas partes, Mallory, que ahora controla evil.example.com, atrae a Alice a su sitio
  3. Una visita a evil.example.com establece una cookie de sesión con el dominio .example.com en el navegador de Alice
  4. Cuando Alice visite www.example.com, esta cookie se enviará junto con la solicitud, como se especifica en las especificaciones de las cookies, y Alice tendrá la sesión especificada por la cookie de Mallory.
  5. Si Alice inicia sesión ahora, Mallory puede usar su cuenta.

Estamos creando una aplicación web donde los clientes tendrán sus propios subdominios: subdomain.ourapp.com .

Cada cliente podrá cargar archivos de plantilla que pueden contener javascript (para la interacción del lado del cliente).

Dado que se puede usar javascript para leer / escribir cookies, ¿cómo podemos evitar el ataque de fijación de sesión anterior? Tenga en cuenta que solo estamos almacenando el ID de sesión en la cookie.

Los sitios como squarespace.com también permiten a los usuarios inyectar su propio javascript en sus páginas en su propio subdominio. Como sería casi imposible intentar filtrar las declaraciones de javascript que configuran / leen las cookies en los archivos de plantilla cargados, ¿cómo podemos mitigar este vector de ataque?

    
pregunta F21 06.04.2013 - 14:35
fuente

5 respuestas

10

El escenario específico se puede prevenir fácilmente: Crear un nuevo ID de sesión al iniciar sesión.

Tenga en cuenta que los problemas existen en los dominios, si el sessionid es un parámetro url.

Sin embargo, la generación de un nuevo sesionide no será suficiente para evitar otros tipos de ataques: una vez que Alice haya iniciado sesión y visite el subdominio de Mallory, ¿se transmitirá la cookie?

Es una práctica común utilizar un dominio completamente diferente para todas las actividades de confianza. Por ejemplo, Google usa google.com para actividades de confianza y * .googleusercontent.com para sitios que no son de confianza.

    
respondido por el Hendrik Brummermann 06.04.2013 - 17:33
fuente
8

La respuesta más segura es usar dominios completamente diferentes.

Si usa subdominios del mismo dominio, comience por conocer los detalles de los posibles ataques. Ya hay mucho escrito sobre esto, en este sitio. Ver, por ejemplo, ¿Qué ataques de cookies son posibles entre computadoras en dominios DNS relacionados (* .example.com)? , Prevención de la aplicación web insegura sobre la seguridad de compromiso de subdominio de la aplicación web principal , Subdominios específicos del usuario: seguridad de JavaScript , mi respuesta a ¿Se incrementa la seguridad al usar un subdominio por cliente en una aplicación web? .

Si usa subdominios del mismo dominio, aquí hay algunos pasos que puede seguir para protegerse: almacenar todo el estado en el lado del servidor (no use cookies para almacenar el estado en el cliente; en cambio, la única cookie que use debería ser una ID de sesión); crear un nuevo ID de sesión en el inicio y cierre de sesión; asegúrese de que la cookie esté dentro del ámbito del subdominio (por ejemplo, su alcance debe ser foo.ourapp.com, no .ourapp.com); verifique en el lado del servidor para asegurarse de que no recibe varias cookies con el nombre; Asegúrese de protegerse contra la fijación de la sesión; Si usa CORS, tenga mucho cuidado con su política de dominios cruzados para asegurarse de que no permita las solicitudes de subdominios cruzados.

    
respondido por el D.W. 06.04.2013 - 22:23
fuente
5

Sufijo público tiene una lista de dominios que todos los proveedores (Chrome / Firefox / IE / Safari / Opera) utilizan para evitar este problema de robar cookies de otros subdominios (junto con otras características). La lista se actualiza diariamente y se mantiene en Github .

Obtuve esta información del blog de Heroku .

He verificado que el dominio googleusercontent.com de Google está incluido en la lista junto con los dominios herokuapp.com , herokussl.com .

    
respondido por el Sairam 20.09.2016 - 12:12
fuente
0

Acabo de tener una idea. Podemos prestada una idea de la cifrado de emergencia Patrón : cifrar el valor de la cookie!

Si solo el servidor accede a la cookie, puede utilizar un cifrado simétrico barato. De lo contrario, utilice el cifrado de clave pública más caro.

Esto le permitirá detectar cuándo subdominios maliciosos eliminan su cookie y / o detectan sus intentos de escribir cookies falsas.

    
respondido por el Gili 10.06.2014 - 16:17
fuente
0

Logré resolver este problema almacenando el subdominio exacto en los datos de la sesión en el servidor. Y enviar un subdominio exacto en la configuración del dominio de cookies.

Si el usuario visita dom1.website.com por primera vez, lo almacenaré en la sesión y verificaré en todas las solicitudes futuras que coincidan con la sesión de reinicio en el servidor.

Por lo tanto, si el usuario que usa el navegador logró trucar el navegador y logró enviar la misma cookie para el código dom2.website.com, verificará que el valor del nombre de dominio almacenado en la sesión no coincida con el dominio contra el que se envió. por lo que se restablecerá la sesión en el servidor.

El único efecto secundario es que la sesión en dom1.website.com también se borrará.

    
respondido por el Faraz 04.08.2017 - 10:54
fuente

Lea otras preguntas en las etiquetas