CSRF en aplicaciones GWT: omitiendo la política del mismo origen

Question

CSRF en aplicaciones GWT: omitiendo la política del mismo origen

#1 de SilverlightFox (2 votos)

0

En el trabajo, sospechamos que una aplicación GWT (que aún no está en producción) que poseemos es vulnerable a CSRF. Tenemos que verlo desde un punto de vista de caja negra antes de que se realice una auditoría de seguridad de terceros.

Debido a que todas las llamadas en la aplicación se realizan a través de AJAX (con el método POST), simplemente no es posible replicar una llamada Ajax de manera maliciosa gracias a la política del mismo origen. De hecho, sabemos que no hay protección csrf, pero dado que solo los cuerpos de solicitud ("carga útil" en la pestaña de red de Chrome) son leídos por el servidor, a primera vista parece que la vulnerabilidad no puede ser explotada.

¿Hay una manera de forjar una solicitud similar a través de un navegador con un formulario clásico? Mi problema es que no puedo replicar el cuerpo de la llamada Ajax a través de un formulario: la aplicación lee el cuerpo de las solicitudes: enviar un formulario de clasificación requiere entradas con pares clave / valor que el servidor no tendrá en cuenta.

En otras palabras, ¿es posible, con un formulario html, enviar una solicitud que solo contenga texto en un cuerpo, en lugar de pares clave-valor en el cuerpo? ¿O hay otro ángulo de ataque para tales casos?

Editar (información adicional):

Los clics en los botones de la aplicación generan solicitudes que usan text/x-gwt-rpc; charset=UTF-8 como content-type que, supongo, es lo que esperan los manejadores de llamadas RPC de GWT, y no se pueden "falsificar" con un navegador normal (por supuesto, tal solicitud podría forjarse sin un navegador, pero está bien, ya que solo estoy tratando de explotar un CSRF potencial).

Lo que más me molesta es el hecho de que sé que no hay tokens CSRF en las solicitudes y que podría existir una manera difícil de falsificar las solicitudes maliciosas, pero no veo cómo.

csrf ajax

pregunta niilzon 27.03.2015 - 12:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas csrf ajax

El navegador no puede autenticar completamente los HTTPS ¿Puedo usar un certificado de CA para dos formas de autenticación (mutua)

score 2 · Accepted Answer

Su aplicación utiliza publicaciones AJAX con el content type establecido en text/x-gwt-rpc .

En otras palabras, ¿es posible, con un formulario html, enviar una solicitud que solo contenga texto en un cuerpo, en lugar de pares clave-valor en el cuerpo?

Según la especificación HTML , solo es posible establecer la siguientes tipos de contenido para un formulario HTML:

application/x-www-form-urlencoded
multipart/form-data
text/plain

Por lo tanto, no es posible configurarlo como text/x-gwt-rpc y que el navegador lo entienda.

Esto denota el "GWT-RPC Wire Protocol" . Con algunos tipos de contenido, podría ser posible "engañar" al navegador para que envíe otro tipo de carga útil utilizando text/plain . Por ejemplo, aquí es cómo se podría hacer con una carga JSON, aunque se enviará sin el encabezado content-type correcto.

<form enctype="text/plain" method="post">

<input type="hidden" name="{&quot;foo&quot;: &quot;bar&quot; }//" value="" />

<input type="submit" />

</form>

se enviaría como

{"foo": "bar" }//=

No es perfecto, pero entiendes la idea.

¿O hay otro ángulo de ataque para tales casos?

Si su aplicación no está verificando el content type del lado del servidor del formulario enviado, es posible que un atacante construya una solicitud AJAX y publique ese dominio cruzado en su servidor. Por ejemplo, pueden establecer que content type sea text/plain , que es dominio cruzado permitido sin una solicitud OPTIONS .

Los tipos de contenido de dominio cruzado permitidos para la solicitud AJAX coinciden exactamente con los tipos de contenido permitidos a través de un formulario HTML.

Una opción para usted podría ser agregar un encabezado a sus solicitudes como X-Requested-With y luego verificar este servidor lado. Como este encabezado no se puede incluir en una solicitud de dominio cruzado sin que el servidor se active a través de CORS, esto protegerá su aplicación contra los ataques CSRF.