Qué es Cross Site Script Inclusion (XSSI)?

Question

Qué es Cross Site Script Inclusion (XSSI)?

Recientemente he visto XSSI mencionado en varias páginas, por ejemplo, Exploits y Defensas de Aplicaciones Web :

Los navegadores impiden que las páginas de un dominio lean páginas de otros dominios. Pero no impiden que las páginas de un dominio hagan referencia a recursos en otros dominios. En particular, permiten que las imágenes se representen desde otros dominios y los scripts se ejecuten desde otros dominios. Un script incluido no tiene su propio contexto de seguridad. Se ejecuta en la seguridad contexto de la página que lo incluyó. Por ejemplo, si www.evil.example.com incluye un script alojado en www.google.com entonces ese script se ejecuta en el contexto malvado no en el contexto de Google. Así que cualquier dato de usuario en ese script " se filtrará."

No veo qué tipo de problemas de seguridad crea esto en la práctica. Entiendo XSS y XSRF pero XSSI es un poco misterioso para mí.

¿Puede alguien bosquejar un exploit basado en XSSI?

Gracias

27

security xss

Author: Pankrat, 2011-11-06

Source

3 answers

XSSI no se limita a las respuestas jsonp. En algunos navegadores se puede anular el constructor de matriz. Si una respuesta Json contiene [...] y la incluye como un script, ejecutará el nuevo constructor en lugar del construido. La solución es insertar algo en la respuesta que no se puede analizar como ])}while(1);</x> y luego usar código para eliminarlo antes de analizarlo. Un atacante no puede hacer eso ya que la inclusión del script es siempre el script completo.

Más detalles sobre el problema y esta solución en http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion

16

Author: Vroo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-02 04:20:26

XSSI es una forma elegante de decir: usted está incluyendo en su programa, alguien elses código; Usted no tiene ningún control sobre lo que está en ese código, y usted no tiene ningún control sobre la seguridad del servidor en el que está alojado.

Por ejemplo, digamos que incluyo en mi página html

<script type="text/javascript" src="http://mymatedave.com/js/coolwidget.js"></script>

Ese script se ejecutará en mi aplicación web con el mismo nivel de confianza que cualquiera de mis propios códigos javascript. Tendrá acceso al contenido de la página completa y DOM, podrá leer todo mi las cookies de la aplicación y leer las pulsaciones de teclas de los usuarios y los movimientos del ratón, y todo lo demás que javascript puede hacer.

Si mi compañero Dave, a continuación, decide poner algo malicioso en su widget fresco (por ejemplo, un sniffer/keylogger que envía todas las cookies del usuario, datos de formulario y pulsaciones de teclas a su servidor) entonces no lo sabré necesariamente. Además, la seguridad de mi aplicación ahora depende de la seguridad del servidor de Dave. Si el servidor de Dave se ve comprometido y coolwidget.js es reemplazado por el atacante, de nuevo no lo haré necesariamente saber y el código malicioso se ejecutará como parte de mi aplicación.

7

Author: Cheekysoft,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-12-01 16:40:18

score 38 · Accepted Answer

Esto suele ser un problema si está utilizando JSONP para transferir datos. Considere un sitio web que consiste en un dominio A que carga datos del dominio B. El usuario debe autenticarse en el sitio A y B, y debido a que la Misma Política de Origen evita que los navegadores más antiguos se comuniquen directamente con un dominio (B) diferente al de la página actual (A), los desarrolladores decidieron usar JSONP. Así que el sitio A incluye un script que apunta a http://B/userdata.js que es algo así como:

displayMySecretData({"secret":"this is very secret", ...})

So A define una función llamada displayMySecretData, y cuando se ejecuta el script incluido del servidor B, llama a esa función y muestra los datos secretos al usuario.

Ahora viene el malvado servidor E. Ve que A está incluyendo datos de B usando JSONP. Así que el servidor E incluye el mismo script, pero define su propio displayMySecretData que en su lugar roba los datos. El atacante engaña al usuario para que visite su sitio. Cuando el usuario va allí y está conectado a B, el navegador envía automáticamente las cookies de autenticación para B junto con la solicitud para fecth el script de B. B ve un usuario autenticado, y por lo tanto devuelve el script como se esperaba. E obtiene los datos, y listo...

Usar JSONP para cargar datos confidenciales de un dominio diferente de esta manera es realmente inseguro, pero la gente todavía lo está usando. Mala idea.