security - site - html form without csrf protection solutions

GWT RPC: ¿hace lo suficiente para protegerse contra CSRF? (4)

ACTUALIZACIÓN : GWT 2.3 presenta un mejor mecanismo para combatir los ataques XSRF. Ver http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html

El mecanismo RPC de GWT hace lo siguiente en cada solicitud HTTP:

Establece dos encabezados de solicitud personalizados: X-GWT-Permutation y X-GWT-Module-Base
Establece 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 lanzan una excepción (método no admitido).

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

La pregunta es: ¿es esto suficiente para prevenir 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?

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

¿Tal vez alguien aquí ya leyó la versión completa del artículo y puede expandirse un poco?

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

Lo que GWT proporciona de inmediato no lo protegerá de CSRF. Debe seguir los pasos documentados en Seguridad para las aplicaciones GWT para mantenerse seguro.

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.

Los encabezados personalizados (X-GWT-Permutation y X-GWT-Module-Base) son un poco más complicados. No pueden establecerse usando HTML. Además, no se pueden configurar con Flash a menos que el servidor lo permita específicamente en crossdomain.xml. Ver la Seguridad de Flash Player 10 .

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

Ahora el RPC de GWT 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, diría que si le importa la seguridad, asegúrese de enviar tokens fuertes de CSRF en su solicitud, y no confíe en GWT para evitarlo.

GWT 2.3 presenta un mejor mecanismo para combatir los ataques XSRF. Ver protección GWT RPC XSRF

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 encabezados prohibidos . 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 algunos exploits 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í y aquí hay 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 últimas reglas , la mayoría de los encabezados se pueden manipular solo para las solicitudes POST.

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