nccgroup/crosssitecontenthijackingPrueba de concepto de secuestro de contenido utilizando Flash, PDF y Silverlight
Publicado bajo AGPL (consulte LICENSE para obtener más información).
Este proyecto se puede utilizar para proporcionar una prueba de concepto para:
Nota: Los archivos .XAP se pueden renombrar con cualquier otra extensión, pero ya no se pueden cargar entre dominios. Parece que Silverlight detecta la extensión del archivo según la URL proporcionada y la ignora si no es .XAP. Esto aún se puede explotar si un sitio web permite a los usuarios usar ";" o "/" después del nombre real del archivo para añadir una extensión ".XAP".
Nota: Los archivos .XAP se pueden renombrar con cualquier otra extensión, pero ya no se pueden cargar entre dominios. Parece que Silverlight detecta la extensión del archivo según la URL proporcionada y la ignora si no es .XAP. Esto aún se puede explotar si un sitio web permite a los usuarios usar ";" o "/" después del nombre real del archivo para añadir una extensión ".XAP".
Nota: Cuando Silverlight solicita un archivo .XAP entre dominios, el tipo de contenido debe ser: application/x-silverlight-app.
Nota: Los archivos PDF solo se pueden usar en el visor de Adobe Reader (no funcionarán con los visores de PDF integrados de Chrome y Firefox).
Nota: La lectura de contenidos estáticos o datos de acceso público no se puede considerar un problema. Es importante eliminar los resultados falsos positivos de sus avisos. Tenga en cuenta que el uso del carácter asterisco ("*") por sí solo en la cabecera "Access-Control-Allow-Origin" no es un problema.
Los tipos de archivo permitidos para subir deben restringirse únicamente a aquellos que sean necesarios para la funcionalidad del negocio.
La aplicación debe realizar filtrado y comprobación de contenido en cualquier archivo que se suba al servidor. Los archivos deben escanearse y validarse minuciosamente antes de ponerse a disposición de otros usuarios. En caso de duda, el archivo debe descartarse.
Añadir las cabeceras "Content-Disposition: Attachment" y "X-Content-Type-Options: nosniff" a la respuesta de los archivos estáticos protegerá el sitio web contra ataques de secuestro de contenido entre sitios basados en Flash o PDF. Se recomienda realizar esta práctica en todos los archivos que los usuarios necesiten descargar en todos los módulos que gestionen la descarga de archivos. Aunque este método no protege completamente el sitio web contra ataques que utilizan Silverlight u objetos similares, puede mitigar el riesgo de usar objetos Adobe Flash y PDF, especialmente cuando se permite subir archivos PDF.
Los archivos de directivas entre dominios Flash/PDF (crossdomain.xml) o Silverlight (clientaccesspolicy.xml) deben eliminarse si no están en uso y no existe un requisito empresarial para que las aplicaciones Flash o Silverlight se comuniquen con el sitio web.
El acceso entre dominios debe restringirse a un conjunto mínimo de dominios que sean de confianza y que requieran acceso. Una directiva de acceso se considera débil o insegura cuando se utiliza un carácter comodín, especialmente en el valor del atributo "uri".
Cualquier archivo "crossdomain.xml" que se utilice para aplicaciones Silverlight debe considerarse débil, ya que solo puede aceptar un carácter comodín ("*") en el atributo de dominio.
El almacenamiento en caché del navegador debe desactivarse para los archivos corssdomain.xml y clientaccesspolicy.xml. Esto permite al sitio web actualizar fácilmente el archivo o restringir el acceso a los servicios web si es necesario. Una vez que se comprueba el archivo de directiva de acceso de cliente, permanece vigente durante la sesión del navegador, por lo que el impacto de no usar caché para el usuario final es mínimo. Esto se puede plantear como un problema de riesgo bajo o informativo según el contenido del sitio web objetivo y la seguridad y complejidad de los archivos de directiva.
Las cabeceras CORS deben revisarse para que solo estén habilitadas para datos estáticos o de acceso público. De lo contrario, la cabecera "Access-Control-Allow-Origin" solo debe contener direcciones autorizadas. Otras cabeceras CORS, como "Access-Control-Allow-Credentials", solo deben usarse cuando sean necesarias. Los elementos dentro de las cabeceras CORS, como "Access-Control-Allow-Methods" o "Access-Control-Allow-Headers", deben revisarse y eliminarse si no son necesarios.
Nota: El uso de la cabecera "Referer" no puede ser una solución, ya que es posible establecer esta cabecera, por ejemplo, enviando una solicitud POST mediante Adobe Reader y PDF (consulte el archivo "xfa-manual-ContentHijacking.pdf" en el directorio "objects"). Actualización: El establecimiento de la cabecera "referer" ha sido abordado por Adobe, a menos que también encuentre un bypass para ello ;)
Consulte la página del proyecto para obtener la última actualización/ayuda: https://github.com/nccgroup/CrossSiteContentHijacking
Soroush Dalili (de NCC Group)
¡Incluso subir un archivo JPG puede conducir al secuestro de datos entre dominios (ataque del lado del cliente)! https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-can-lead-to-cross-domain-data-hijacking-client-side-attack/
Múltiples vulnerabilidades en PDF: texto e imágenes con esteroides http://insert-script.blogspot.co.at/2014/12/multiple-pdf-vulnerabilites-text-and.html
Comunicación HTTP y seguridad con Silverlight http://msdn.microsoft.com/en-gb/library/cc838250(v=vs.95).aspx
Explicación de los archivos de directivas de acceso entre dominios y de cliente para Silverlight http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight
Especificación del archivo de directiva entre dominios http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Configuración de un archivo crossdomain.xml para transmisión HTTP http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html
Explotando CVE-2011-2461 en google.com http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html
