CSRF y Flash / Flex

Question

CSRF y Flash / Flex

#1 de Sajjad Pourali (2 votos)

4

Los clientes Flash y Flex pueden realizar llamadas RPC a un servidor utilizando los protocolos NetConnection y AMF. No es raro que estas configuraciones de llamadas RPC se autentiquen en función de una cookie.

He escuchado declaraciones contradictorias sobre si este protocolo (o cualquier implementación de tamaño de servidor en particular, como BlazeDS, GraniteDS, etc.) aborda la vulnerabilidad de falsificación de solicitudes entre sitios. Parecería que sin alguna funcionalidad especial aquí, se podría falsificar una solicitud de envío de formulario que ejecuta una llamada RPC que secuestra la cookie de sesión de un usuario.

¿Alguien puede confirmar o negar si existe una vulnerabilidad aquí?

web-application csrf flash

pregunta Marplesoft 09.09.2013 - 21:59

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application csrf flash

¿Qué tan efectiva es Caja para prevenir el XSS? Diseñar un entorno PKI

score 2 · Answer 1

Los applets de Flash se pueden usar para explotaciones de CSRF pero dependen de la política del mismo origen o XML-RPC o similar.

Si desea enviar una solicitud XML-RPC con un cuerpo xml en un formulario html, debe utilizar un formulario como este:

<form name="x" enctype="text/plain" action="" method="post">
<input type="hidden" name='<?xml version'value='"1.1"?><a><b>blah blah</b></a>'>
</form>
<script>document.x.submit();</script>

(Pero si la aplicación web o el servidor comprueban el tipo de contenido, no funcionará.)

y para la política del mismo origen:

CSRF en Plupload (CVE-2012-3415)

El applet de Plupload llamado Security.allowDomain ('*') para permitir que el applet se use desde cualquier dominio (por lo que podría servirse desde S3, por ejemplo). Eso significaba que las personas podían interactuar con el applet Plupload desde cualquier otro sitio en Internet al insertarlo en una página y usar JavaScript. Pero debido a la forma en que funciona la política del mismo origen en Flash, el applet aún podría realizar solicitudes al dominio en el que estaba alojado. Además, las personas pueden especificar la URL completa para una solicitud de carga a través de JavaScript y el resultado de esa solicitud (es decir, el HTML de la página resultante) se devuelve a través de JavaScript a la página de incrustación.

Por lo tanto, si un atacante podría convencer a un objetivo de que interactúe con el applet (seleccionando un solo archivo para cargar), el atacante podría solicitar al dominio en el que se alojó el applet y volver a leer la respuesta completa. Eso podría revelar tokens CSRF u otra información confidencial. Este problema fue especialmente importante para las instalaciones de Wordpress, donde los applets de Plupload se alojan dentro del directorio wp-includes de forma predeterminada.

El problema se resolvió eliminando la llamada a Security.allowDomain ('*') de forma predeterminada.

Además, los applets de Flash también pueden tener vulnerabilidades de XSS. Leer más y hacer referencia