GWT RPC - ¿Se hace lo suficiente para proteger contra CSRF?

Question

Actualizar : GWT 2.3 introduce un mecanismo mejor para luchar contra los ataques XSRF. Ver http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf .html

---

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

1. Establece dos cabeceras de petición Personal - X-GWT-permutación y X-GWT-Módulo Base-
2. Define el tipo de contenido como texto / x-GWT-RPC; charset = utf-8

La petición HTTP es siempre un poste, y en el servidor métodos GET lado una excepción (método no es compatible).

Además, si estas cabeceras no es ajustado o tiene el valor incorrecto, el servidor no se puede procesar con una excepción "posiblemente CSRF?" o algo por el estilo.

La pregunta es: ¿Es esto suficiente para evitar CSRF? ¿Hay una manera de cabeceras personalizadas conjunto y el tipo de cambio en el contenido de un método de falsificación de petición en sitios cruzados pura?

Answer 1

Si esto GWT RPC está siendo utilizado por un navegador, entonces es 100% vulnerables a CSRF. El tipo de contenido se puede ajustar en el elemento html <form>. X-GWT-Permutation y X-GWT-Module-Base no están en la lista de negro de destello de cabeceras prohibidas . Por lo tanto, es posible llevar a cabo un ataque CSRF el uso de flash. El único elemento de cabecera de confianza para la protección CSRF es el "árbitro", pero esto no es siempre el mejor enfoque. Uso simbólico protección CSRF basadas siempre que sea posible.

Estos son algunos exploits que he escrito que debe arrojar alguna luz sobre el ataque oscura que estoy describiendo. Un destello explotar para este quedará del siguiente modo este aquí es un js / html exploit que cambia el tipo de contenido.

Mi hazaña fue escrito para Flex 3.2 y las reglas han cambiado en Flex 4 (Flash 10) Estos son los últimas reglas , la mayoría de las cabeceras puede ser manipulado por sólo solicitudes POST.

script de flash que usa navigateTo() para CSRF: https://github.com/TheRook/CSRF-Request-Builder

Answer 2

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

Answer 3

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

Lo que GWT ofrece fuera de la caja no le protegerá de CSRF. Usted tiene que tomar pasos indicados en el de seguridad para GWT aplicaciones para permanecer asegurado.

GWT RPC establece "de tipo de contenido" de cabecera a "text / x-GWT-RPC; charset = UTF-8". Si bien no he encontrado una manera de hacer esto usando formularios HTML, es trivial para hacerlo en flash.

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

  

Además, cuando un archivo SWF desea   enviar cabeceras HTTP personalizados en cualquier lugar   con excepción de su propio anfitrión de origen,   debe haber un archivo de política en el   servidor HTTP al que la solicitud es   siendo enviado. Este archivo de política imprescindible   enumerar host del archivo SWF de   origen (o un conjunto mayor de hosts) como   de permitir enviar cualquier petición de encargo   encabezados en ese host.

Ahora RPC de GWT viene en dos sabores. No es la edad, a medida serialización formato RPC, y el nuevo, JSON-RPC con base de. AFAICT, código de cliente siempre establece estas cabeceras de petición. El viejo estilo RPC no ahora hacer cumplir estas cabeceras en el lado del servidor, y por lo tanto un ataque CSRF es posible. El nuevo estilo de-RPC hace cumplir estas cabeceras, y por lo tanto puede o no puede ser posible atacarlos.

En general, yo diría que si se preocupan por la seguridad, asegúrese de enviar fuertes señales CSRF de su parte, y no se basan en GWT para evitar que para usted.

Answer 4

No estoy seguro, si hay una manera fácil (Estaría muy interesado en encontrar eso también!), Pero al menos parece que hay algunas formas avanzadas para lograr las solicitudes entre sitios arbitrarios con cabeceras arbitrarias: http://www.springerlink.com/content/h65wj72526715701/ no he comprado el papel, pero el resumen y la introducción hacerlo sonido muy interesante.

Tal vez alguien aquí ya leer la versión completa del artículo, y se puede ampliar un poco?