Crossdomain.xml - acceso de escritura al dominio

Question

Crossdomain.xml - acceso de escritura al dominio

#1 de SilverlightFox (0 votos)

0

¿Una política permisiva de crossdomain.xml Flash es análoga a una política permisiva de CORS?

es decir, Es

<cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

el equivalente de

Access-Control-Allow-Origin: <origin request header>
Access-Control-Allow-Credentials: true

por ejemplo si el sitio del atacante es attacker-site.co.uk sobre TLS, se reflejarán los siguientes encabezados:

Access-Control-Allow-Origin: https://attacker-site.co.uk
Access-Control-Allow-Credentials: true

Argumentaría que la política de Flash hace que las cosas sean más inseguras (solo desde una perspectiva de Flash) porque aunque parecen permitir las mismas cosas, Flash no permite el acceso de escritura a menos que exista un archivo de políticas de dominio cruzado permisivo, mientras que el acceso de escritura a un origen está permitido por defecto dentro de la Política de Same Origin .

Sin embargo, dado que el acceso de escritura está permitido de todos modos (no Flash), permitirlo también en Flash no agrega ningún riesgo de integridad a la aplicación. ¿Esto es correcto?

flash same-origin-policy cors

pregunta SilverlightFox 10.06.2017 - 10:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas flash same-origin-policy cors

¿Ocultar computadoras detrás de redis pub / sub? ¿Pueden los hackers falsificar una dirección IP? [duplicar]

score 0 · Accepted Answer

Sí, aunque los permisos predeterminados de origen cruzado difieren entre Flash y HTML:

       Write Access (e.g. POSTing data)            Read Access (e.g. req allowing data to be read)

HTML   Allowed                                     Only allowed with CORS
Flash  Not allowed without cross domain policy     Not allowed without cross domain policy

Habiendo dicho esto, es posible realizar un ataque CSRF utilizando Flash sin una política de dominio cruzado. Evgeniy Yakovchuk ha publicado un Github que muestra un POC del problema. Esto implica que el archivo Flash realice una solicitud a una URL en el mismo origen que el archivo .swf; sin embargo, el controlador de esta URL emite un redireccionamiento 307 que hace que la solicitud se envíe al sitio de la víctima. El archivo crossdomain.xml no se verifica antes de que la solicitud se haya redirigido y se logre el CSRF, también con la opción de establecer un encabezado personalizado content-type que omita las restricciones habituales de la Política del mismo origen del navegador.

Si esto es "por diseño" es para que Adobe lo confirme. Ellos corrigieron una variación en esto que también permitió agregar encabezados personalizados que normalmente no están permitidos sin una política CORS relevante, sin embargo El problema de redireccionamiento 307 aún permanece.

Volviendo a la tabla anterior, ya que el acceso está permitido por HTML de todos modos, permitir que Flash "escriba" en otro origen tampoco aumenta el riesgo.

Ambos métodos, como ya se mencionó, también requieren configuraciones adicionales para los encabezados: Flash no puede enviar encabezados personalizados con una solicitud a menos que exista la configuración adecuada en crossdomain.xml :

<allow-http-request-headers-from domain="www.example.com" headers="MyHeader"/>

Y cualquier encabezado personalizado requiere una solicitud de prevuelo en HTML a Asegúrate de que la configuración del servidor lo permita.

Con respecto al riesgo de integridad (dentro de la tríada de la CIA ), ambos podrían causar un riesgo indirecto si la política lo permite. tokens anti-CSRF para leer que luego podrían usarse para hacer solicitudes de cambio de estado a la aplicación.