site sheet reflected prevent how explotar cross cheat avoid xss security

sheet - ¿Qué es la inclusión de secuencias de comandos entre sitios(XSSI)?



xss php (3)

Recientemente he visto XSSI mencionado en varias páginas, por ejemplo, ataques a la aplicación web y defensas :

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 el contexto de seguridad de la página que lo incluyó. Por ejemplo, si www.evil.example.com incluye un script alojado en www.google.com, ese script se ejecuta en el contexto malvado, no en el contexto de Google. Por lo tanto, cualquier dato de usuario en ese script se "filtrará"

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

¿Alguien puede esbozar un exploit basado en XSSI?

Gracias


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 los sitios A y B, y porque la misma política de origen impide que los navegadores antiguos se comuniquen directamente con un dominio diferente (B) que la página actual (A), los desarrolladores decidieron usar JSONP. Entonces, el sitio A incluye un script que apunta a http://B/userdata.js que es algo así como:

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

Así que 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 servidor malvado E Ve que A incluye 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 luego engaña al usuario para que visite su sitio. Cuando el usuario va allí y ha iniciado sesión en B, el navegador envía automáticamente las cookies de autenticación para B junto con la solicitud para corregir el script de B. B ve a un usuario autenticado y, por lo tanto, devuelve el script como se esperaba. E obtiene los datos, y listo ...

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


XSSI es una forma elegante de decir: usted está incluido en su programa, el código de otra persona; No tiene ningún control sobre lo que hay en ese código, y 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 al DOM, podrá leer todas las cookies de mi aplicación y leer las pulsaciones de teclas y los movimientos del mouse de los usuarios, y todo lo que puede hacer javascript.

Si mi compañero dave, decide poner algo malicioso en su genial widget (por ejemplo, un sniffer / keylogger que envía todas las cookies del usuario, datos de formulario y pulsaciones de tecla a su servidor), entonces no necesariamente lo sabré. 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 sabré necesariamente y el código malicioso se ejecutará como parte de mi aplicación.


XSSI no se limita a las respuestas jsonp. En algunos navegadores puedes anular el constructor Array. Si una respuesta de Json contiene [...] y la incluye como un script, ejecutará el nuevo constructor en lugar del incorporado. La solución es insertar algo en la respuesta que no se pueda analizar como ])}while(1);</x> y luego usar el 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