¿Utilizar la vulnerabilidad XSS en iframe para comprometer a los padres?

Los iframes tienen una etiqueta especial llamada "sandbox" que establece cómo tratar el contenido del iframe. Usando esa etiqueta, puede establecer permisos granulares para permitir que un iframe interactúe con el padre. Normalmente, los iframes son bastante restrictivos en cuanto a cómo pueden afectar a un padre cuando se cargan desde un dominio diferente, pero si ve cosas como: permitir el mismo origen, permitir scripts, permitir la navegación superior, etc. puede haber casos específicos. formas de explotarlo.

[editar] La mayoría de los casos de ataques iframe XSS no implican realmente la inyección de código arbitrario en el sitio web principal. En su lugar, suelen ser uno de los siguientes:

1. Usted toma el control del sitio web secundario y lo reemplaza con algo como un formulario de inicio de sesión falso para hacer que la gente piense que está iniciando sesión en el sitio web principal para acceder al contenido, cuando realmente está falsificando sus credenciales.
2. Usted distribuye un servicio "útil" que otros programadores incorporan en sus sitios que realmente utiliza para falsificar información privada. Luego rezas por la confianza de la gente en estos otros sitios web para que te den algo útil. Por ejemplo: una calculadora de tramos de impuestos que solicita su nombre, dirección y número de Seguro Social.
3. En lugar de parent.com, crea un sitio gemelo malvado llamado parents.com que contiene parent.com dentro de un iframe para que se comporte como el sitio real, pero su versión del sitio web recopila los datos privados del usuario final. información.

Por lo tanto, la forma más probable para que usted pueda explotar este escenario sería si pudiera reemplazar el formulario con algo que parezca un formulario de inicio de sesión para parent.com y no publicar en parent.com, sino en algo que realmente controlas para robar las credenciales de los usuarios.

Es probable que esto no sea posible ya que los marcos son restrictivos por naturaleza. Recuerde que todo lo que es un iFrame es una simple solicitud GET para el sitio incluido como fuente, y luego incrustarlo en el sitio principal y permitir una mayor interacción con él. Ha descrito una vulnerabilidad POST-XSS dentro del sitio secundario, lo cual sería muy difícil de activar automáticamente en un iframe, como lo es una vez más, solo una solicitud GET.

Hablando teóricamente, es obvio que podría encontrar una vulnerabilidad de navegador que le permitiría ejecutar javascript desde un sitio secundario a un sitio principal, pero tal cosa es mucho más valiosa que cualquier recompensa en el sitio principal. Además, es probable que aún no funcione en su caso, ya que nuevamente solo tiene POST-XSS.

Es útil tener en cuenta que aunque los iFrames son restrictivos como lo señalan otros usuarios y yo mismo, existe una excepción para el javascript: URI. Tomemos, por ejemplo, un iframe como este:

<iframe src="javascript:alert(0)"></iframe>

Si esto estuviera en un sitio web, no solo recibiría una alerta, sino que sería una alerta en el "sitio principal" ya que técnicamente no hay un sitio secundario. Este es un comportamiento interesante y demuestra que los iFrames no siempre son tan ' restrictivos '.