GWT RPC: ¿hace lo suficiente para proteger contra CSRF?

ACTUALIZACIÓN: GWT 2.3 presenta un mejor mecanismo para combatir ataques XSRF. Ver http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html GWT RPC: ¿hace lo suficiente para proteger contra CSRF?

mecanismo RPC GWT hace las siguientes cosas a todas las peticiones HTTP -

conjuntos de dos cabeceras de petición Personal - X-GWT-permutación y X-GWT-módulo-Base
Sets el tipo de contenido como text/x-gwt-rpc; charset = utf-8

La solicitud HTTP es siempre una POST, y en el lado del servidor, los métodos GET generan una excepción (método no admitido).

Además, si estos encabezados no están configurados o tienen un valor incorrecto, el servidor falla el procesamiento con una excepción "posiblemente CSRF?" O algo por el estilo.

La pregunta es: ¿Esto es suficiente para evitar el CSRF? ¿Hay alguna forma de establecer encabezados personalizados y cambiar el tipo de contenido en un método puro de falsificación de solicitudes entre sitios?

Fuente

2010-04-09 Sripathi Krishnan

Si este GWT RPC está siendo utilizado por un navegador, entonces es 100% vulnerable a CSRF. El tipo de contenido se puede establecer en el elemento html <form>. X-GWT-Permutation y X-GWT-Module-Base no están en la lista negra de Flash de banned headers. Por lo tanto, es posible realizar un ataque CSRF usando flash. El único elemento de encabezado en el que puede confiar para la protección de CSRF es el "referer", pero este no es siempre el mejor enfoque. Utilice la protección CSRF basada en token siempre que sea posible.

Aquí hay algunas hazañas que he escrito que deberían arrojar algo de luz sobre el oscuro ataque que estoy describiendo. Un exploit flash para esto se verá algo así como this y here es un exploit js/html que cambia el tipo de contenido.

Mi exploit fue escrito para Flex 3.2 y las reglas han cambiado en Flex 4 (Flash 10) Aquí están las latest rules, la mayoría de los encabezados se pueden manipular solo para las solicitudes POST.

guión

Flash que utiliza navigateTo() para CSRF: https://github.com/TheRook/CSRF-Request-Builder

Fuente

2010-04-09 18:49:28 rook

XmlHttpRequest, Flash y una serie de otras tecnologías pueden configurar encabezados de explorador personalizados, pero la política de origen mismo se activa y evitará que otro sitio realice la solicitud. A menos que el servidor tenga un crossdomain.xml indulgente o devuelva Access-Control-Allow-Origin a sitios web arbitrarios, ¿cómo va a funcionar la solicitud? Eso solo nos deja con forms/images/iframes y similares, donde no se aplica la misma política de origen. Pero no sé de qué manera pueden establecer encabezados http personalizados. Entonces, ¿cómo es vulnerable? –

.. y sí, estoy de acuerdo con que la protección csrf basada en token es la mejor manera, pero me gustaría entender el error con su enfoque. –

@sri Muy buena pregunta. Para poder aprovechar este exploit, debes aprovechar una propiedad poco conocida de flash. He publicado 2 exploits que hacen lo que estoy describiendo, te animo a que los uses. (Si no tiene el software vulnerable como mínimo, puede ver que la solicitud POST se está enviando a otro dominio, pero el script no puede "ver" una respuesta debido al SOP) – rook

No estoy seguro, si hay una manera fácil (que estaría muy interesado en encontrar eso también!), Pero al menos no parece Hay algunas formas avanzadas de lograr solicitudes arbitrarias entre sitios con encabezados arbitrarios: http://www.springerlink.com/content/h65wj72526715701/. No compré el artículo, pero el resumen y la introducción suenan muy interesantes.

Quizás alguien aquí ya haya leído la versión completa del artículo y pueda ampliarlo un poco?

Fuente

2010-04-09 20:03:19

Postulé para flashear el código fuente que escribí, que modifica los encabezados http y publicar para aprovechar una vulnerabilidad csrf. – rook

@rook: pero vuelva a publicarlo. – user2284570

Sé que hice esta pregunta, pero después de aproximadamente un día de investigación (gracias a los consejos de Rook!), Creo que tengo la respuesta.

Lo que GWT proporciona de fábrica no lo protegerá de CSRF. Debe seguir los pasos documentados en Security for GWT Applications para mantenerse protegido.

GWT RPC establece el encabezado "content-type" en "text/x-gwt-rpc; charset = utf-8". Si bien no encontré una forma de configurar esto usando formularios HTML, es trivial hacerlo en flash.

Las cabeceras personalizadas - X-GWT-Permutación y X-GWT-módulo-base, son un poco más complejo. No pueden establecerse usando HTML. Además, no se pueden configurar utilizando Flash a menos que su servidor lo permita específicamente en crossdomain.xml. Ver Flash Player 10 Security.

Además, cuando un archivo SWF desea enviar cabeceras HTTP personalizados en cualquier lugar distinto de su propio anfitrión de origen, debe haber un archivo de política en el servidor HTTP a la que se envía la solicitud . Este archivo de política debe enumerar el host del archivo SWF del origen (o un conjunto más grande de hosts) como que le permite enviar encabezados de solicitud personalizados a ese host.

Ahora GWT's RPC viene en dos sabores. Existe el antiguo formato de serialización personalizado RPC y el nuevo de-RPC basado en JSON. AFAICT, el código del cliente siempre establece estos encabezados de solicitud. El RPC antiguo no impone ahora estos encabezados en el lado del servidor y, por lo tanto, es posible un ataque CSRF. El nuevo estilo de-RPC impone estos encabezados, y por lo tanto puede o no ser posible atacarlos.

En general, yo diría que si le importa la seguridad, asegúrese de enviar tokens CSRF fuertes en su solicitud, y no confíe en GWT para evitarlo.

Fuente

2010-04-10 20:30:31

@sri, estas son las nuevas reglas para establecer encabezados: http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html Solo puede establecerlas en POST, y las comunes son negras enumerados, de acuerdo con toda la información que ha publicado, el elemento de encabezado "X-GWT-Permutation" se puede controlar para las solicitudes POST utilizando el método que utilicé en mi exploit de carga de archivos entre sitios. – rook

Echa un vistazo a este código de ejemplo que cambia el elemento de encabezado 'pragma: no-cache': http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html#URLRequestHeader%28%29 Si tuvo problemas para compilar mi código, debería intentar compilar el ejemplo. – rook

Su respuesta fue exactamente lo que estaba buscando, pero data de 2010. Estoy tratando de escribir un ataque PoC CSRF contra el RPC antiguo, usando una versión moderna de flash. ¿Sabes si esto todavía es posible? Como el objetivo _no tienet_t_crossdomain, xml_. Parece que mi cliente Flash está enviando una solicitud de _crossdomain, xml_ al servidor, se da cuenta de que no hay tal archivo, y luego no procede a emitir mi carga de CSRF. ¿Las nuevas versiones de Flash han evitado esencialmente este tipo de ataque, incluso en el RPC antiguo? – Juicy

GWT 2.3 introduce un mecanismo mejor para luchar contra los ataques XSRF. Consulte GWT RPC XSRF protection

Fuente

2011-09-07 18:42:40 rjrjr

actualizó la pregunta para que cualquiera que visite esta página pueda encontrarla fácilmente. ¡Gracias! –

¿Alguno de los participantes independientes verificó que la implementación actual (GWT 2.8.1) XsrfTokenServlet proporciona una forma segura de protección contra XSRF? – user1050755

GWT RPC: ¿hace lo suficiente para proteger contra CSRF?

Respuesta

Cuestiones relacionadas