Pensé que clientes como Gmail.com y Outlook.com pondrían los correos electrónicos en un iframe para mayor seguridad, pero resulta que están muy bien desinfectados con algo como Caja.
Pero, ¿hay alguna razón en particular por la que no usarían iframes, que al menos ayudaría un poco a sandbox?
(Caja, por ejemplo, se encontró una vulnerabilidad hace unos meses , y creo que esta vulnerabilidad puede haberse mitigado al colocar correos electrónicos en un iframe)
TL; DR iframe no puede reemplazar el saneamiento por completo, pero es una excelente característica para usar como seguridad en profundidad. Desafortunadamente, sí interfiere con algunas características de facilidad de uso.
Me gustaría escuchar una respuesta más informada, pero voy a publicar algunos puntos que conozco.
La misma política de origen funciona en ambos sentidos. Es fantástico que evite que iframe vea el contenido del documento externo. Desafortunadamente, si selecciona texto, el documento externo no puede indicar qué texto se seleccionó en el iframe . ( thanks @ paj28 ) Una vez podría usar la función postMessage agregando un script a la página interna para solucionar esto, pero es un inconveniente. Además, esto no funcionará si utiliza iframe sandbox como una manera de deshabilitar script s. (que recomiendo encarecidamente)
Querrá usar Política de seguridad de contenido (de nuevo, thanks @ paj28 ) para deshabilitar las balizas dentro del contenido iframe d; y también para deshabilitar scripts y otros posibles problemas.
Me gustaría señalar que iframe como se diseñó originalmente no está completo. El sandbox attribute sería obligatorio si tiene alguna duda sobre su saneamiento. Desafortunadamente, la función sandbox solo se implementada recientemente . Esto tiene una importancia cada vez menor a medida que los navegadores antiguos comienzan a abandonar los gráficos.
La desactivación de secuencias de comandos obstaculizaría las funciones de facilidad de uso de todos modos, como la detección de texto seleccionado. (Es posible que pueda salirse con la opción "deshabilitar los scripts y tratarlos como la misma regla de origen" de la zona de pruebas, pero eso parece arriesgado).
Cada vez que agregue sus propios scripts o funciones interactivas al documento iframe 'd, estará mucho más seguro si aún lo desinfecta. Si bien iframe sandbox combinado con CSP puede cubrirlo completamente, es posible que falte algo en esa fórmula.
Así que en resumen
Para los navegadores que no admiten sandbox , iframe mitiga los riesgos de seguridad significativos, pero no puede protegerse contra muchos problemas. La Política de seguridad del contenido podría aislar el contenido, en gran medida. Pero aún debes desinfectar para prevenir cosas como <a target="_top" .
Para los navegadores que admiten sandbox , combinado con una buena Política de seguridad de contenido, puede reemplazar el saneamiento, pero no es recomendable porque es difícil saber si está 100% seguro. . (Por otro lado, las rutinas de saneamiento son más antiguas y están mejor revisadas)
Si tiene un saneamiento (que probablemente debería) y el saneamiento está bien examinado, entonces iframe s solo interfiere con la facilidad de uso. Por otro lado, si se descubre una falla en su saneamiento, entonces se alegrará de que iframe d el contenido, utilizando el atributo sandbox y el CSP para reducir el alcance del ataque.
Nota al margen: las aplicaciones de escritorio tienen más libertad en el sandboxing de sus vistas web, incluso mejor que el atributo iframe sandbox. Así, por ejemplo, las aplicaciones de Android podrían beneficiarse.
Para servir cualquier contenido dentro de un iFrame, Google tendría que deshabilitar algunos de los scripts de rompecorazones existentes en el sitio (que Google habría agregado como mitigación contra clickjacking para clientes web más antiguos).
Me imagino que Google determinó que el riesgo de deshabilitar las secuencias de comandos de framebreaker sería mayor que la recompensa de representar el contenido en un iFrame.