Estoy tratando de crear una plataforma extensible, donde mi sitio proporcionará un modelo y algunas vistas (tanto del lado del cliente, en el navegador) como las de terceros también pueden agregar sus propias vistas. El objetivo aquí es que solo mi modelo realizará solicitudes HTTP a mi servidor, y las vistas de terceros solo harán llamadas API a mi plataforma, nada más (también pueden "llamar a casa" si lo desean, pero no deben tocarlas). cualquier cosa que no esté explícitamente expuesta a ellos a través de la API).
La solución propuesta es crear un iframe invisible para cada extensión de terceros, utilizando solo postMessage para comunicarse con ellos ( Editar : para ser una "vista" adecuada, debe ser visible, por supuesto, pero como alternativa, simplemente puede tener el rol de "controlador", delegando el renderizado de componentes visuales a la página principal - podría usarse si se agregara algún beneficio de seguridad, pero idealmente no). ¿Sería esto correctamente "sandbox" el código? Estoy asumiendo que:
- No podrán acceder al DOM de la página principal ni realizar llamadas arbitrarias de JavaScript ni realizar una solicitud de Ajax en mi dominio, debido a la política del mismo origen;
- Es posible que realicen solicitudes GET en mi servidor (incluida la carga de scripts desde él), pero siempre que use tokens CSRF donde sea importante, debería estar bien. Esta situación no es diferente de tener dos pestañas abiertas en el mismo navegador, una de ellas autenticada con su sitio respectivo;
- No podrán hacer clickjack al usuario,
desdesi sus iframes son invisibles; También asumo que no pueden hacerlos visibles o cambiar su tamaño, ya que esto implicaría acceder al DOM de la página principal, ¿es correcto? - Ellos pueden spam
Window.alert(o peor:Window.prompt),console.logo acceder a otras cosas "globales". Este es el peor problema que identifiqué hasta ahora, y aún no puedo pensar en formas de evitarlo.- Aclaración: el problema aquí es la posibilidad de intentar suplantar el sitio principal, mostrando un mensaje pidiendo la contraseña, por ejemplo.
- También, corríjame si me equivoco. Asumo que JavaScript en iframes tiene igual acceso a esos recursos, y no hay manera de que la página principal lo niegue.
- pueden incrustar flash u otros complementos que pueden tener vulnerabilidades de seguridad. El hecho de que esté en un iframe, sin embargo, no lo empeora en ningún aspecto, ¿o me equivoco?
¿Son correctas estas suposiciones? ¿Hay algo más que deba tener en cuenta? Será necesario un cierto nivel de confianza por parte de los usuarios (la idea es que cada usuario debería poder elegir extensiones a su propio ritmo, independientemente de que mi sitio las respalde o no, mientras que en última instancia, tenga las consecuencias de sus elecciones), pero Me gustaría hacer todo lo posible para mitigar esos riesgos.
Actualización: Me gustaría aclarar un poco la pregunta, en función de las preguntas formuladas por los comentaristas. Hay muchas razones para incluir scripts de terceros en una página: publicidad, análisis, interacción con redes sociales, etc. Sin embargo, esto es un problema de seguridad, de hecho, es una de las razones por las que las personas usan AdBlock o NoScript (para que pueda elegir de forma selectiva qué dominios están autorizados para ejecutar código en su navegador). Por lo general, el sitio confía en los terceros cuyos scripts incluye, pero no siempre (las aplicaciones de Facebook, por ejemplo, pueden ser creadas por cualquier persona, pero se ejecutan dentro de una página de Facebook), y he visto que iframes se han utilizado para "aislar" a terceros. contenidos de la fiesta.
Aunque una opción para la comunicación entre sitios en el navegador es tener dos pestañas abiertas (o ventanas) que usan postMessage para intercambiar mensajes, una sola página proporciona una experiencia más fluida. Mi principal preocupación en esta pregunta es la implicación total de usar iframes (visible o invisible) y su viabilidad en el uso de contenidos no fiables en la zona de pruebas de arena, y el IMHO también es aplicable para una audiencia más amplia (consulte el párrafo anterior).
En mi caso particular, estoy tratando de evitar que los contenidos incrustados se hagan pasar por el sitio principal (vea la aclaración en el cuarto punto anterior) y de proteger a los usuarios en general de otras molestias en la medida de lo posible. Si bien cada usuario tendrá la capacidad de elegir sus propias extensiones, siendo responsable en última instancia de las consecuencias, me gustaría mitigar cualquier problema conocido que esté a mi alcance (y tratar de educar a los usuarios para aquellos que no lo están).