Prevenir la petición en sitios cruzados falsificación - Nunca confiar en el SessionID envían a su servidor en la cabecera de la galleta

Estoy leyendo el tutorial enPrevenir la petición en sitios cruzados falsificación - Nunca confiar en el SessionID envían a su servidor en la cabecera de la galleta

http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

Afirma

Recuerde - usted debe nunca confíe en el ID de sesión enviado a su servidor en el encabezado de la cookie ; solo mire el ID de sesión que su aplicación GWT envía explícitamente en la carga de los mensajes a su servidor.

¿Se utilizan para evitar http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Con esta mitología, es lo suficientemente suficiente para impedir a los ataques de arriba?

Fuente

2010-04-05 Cheok Yan Cheng

Sí, es suficiente para evitar la falsificación de solicitudes entre sitios.

No se puede confiar en el sessionid en la cookie. Supongamos que un usuario ha iniciado sesión en mysite.com y que la identificación de sesión está en la cookie. Ahora el usuario hace clic en un enlace a evilsite.com. evilsite.com tiene un código como éste

<img src="http://mysite.com/transfermoney.jsp?amount=1000.." />

El navegador hará una petición a mysite.com, y se enviará también a lo largo de la galleta con el id de sesión. Lo que hay que entender aquí es que evilsite.com no puede leer la cookie, pero aún puede hacer su trabajo.

La política del mismo origen del navegador evita que evilsite.com lea el identificador de la sesión, ya sea en la cookie o incrustado en la página html. Pero debido a que el navegador envía automáticamente la cookie a su servidor , incluso si el recurso se solicitó desde el código html en otro dominio, tiene XSRF.

Para evitar esto, se recomienda poner el identificador de sesión como un parámetro de solicitud. Si se agrega como un parámetro de solicitud, evilsite.com no puede acceder al identificador y, por lo tanto, no puede ponerlo en el atributo img src.

Sin embargo, recuerde que si su sitio tiene vulnerabilidades XSS, nada puede impedir que XSRF. En otras palabras, si tiene vulnerabilidades XSS, un atacante ni siquiera se preocuparía por hacer XSRF.

Fuente

2010-04-05 17:23:36

@Sripathi: ¡Esta es una muy buena respuesta a una muy buena pregunta! El problema práctico que veo es que las personas están acostumbradas a "permanecer conectadas", incluso si cierran una ventana del navegador, o si utilizan otras ventanas del navegador para visitar el mismo sitio, y esperan estar todavía conectadas. Por lo tanto, si mi el sitio no proporciona esa funcionalidad (para contrarrestar los ataques CSRF), me temo que ellos verán mi sitio como de "baja calidad", es decir, "¿por qué otros sitios pueden hacer eso, pero no el suyo?" Realmente puedo entender esa actitud. ¿Hay alguna forma de combinar ambas ventajas o encontrar un buen compromiso? –

Es posible. CSRF es principalmente un problema con APIS de estilo AJAX, donde una única solicitud es todo lo que se necesita para hacer algo dañino. Para tales solicitudes de API, no debe confiar únicamente en la cookie de larga duración y recuerdo. Sin embargo, está bien renderizar páginas de solo lectura utilizando solo la cookie, ya que el atacante no puede leer el contenido con solo csrf. –

Creo que ese es el mejor compromiso. Todavía me siento un poco inseguro, sin embargo, porque recuerdo haber leído un artículo (http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html) sobre una técnica de cómo robar ciertos tipos de datos de la respuesta de un CSRF, aunque en realidad no debería ser posible. Espero que sea imposible expandir esto más allá de los resultados de JavaScript, porque podemos suponer con seguridad que se rompe con el primer carácter '<' más o menos? Si no podemos, los usuarios tendrían que iniciar sesión para cada pestaña del navegador por separado ... –

Prevenir la petición en sitios cruzados falsificación - Nunca confiar en el SessionID envían a su servidor en la cabecera de la galleta

Respuesta

Cuestiones relacionadas