2012-02-14 24 views
57

Estoy en el proceso de desarrollar una aplicación para un cliente, que tendrá un certificado SSL y se servirá bajo https. Sin embargo, para integrarse con su sitio existente, quieren proporcionar su navegación dentro de un iframe.Contenido inseguro en iframe en la página segura

Veo que esto causa problemas, ya que supongo que el navegador se quejará de la combinación de contenido seguro e inseguro en la página. He echado un vistazo a las preguntas similares aquí y todas parecen referirse a esto al revés (contenido seguro en el iframe).

Lo que me gustaría saber, entonces, es: ¿causará problemas tener contenido inseguro incluido dentro de un iframe, colocado en una página segura, y en caso afirmativo, qué tipo de problemas serían?

Idealmente, si no es una buena idea (y tengo la fuerte sensación de que no lo es), debo ser capaz de explicar esto al cliente.

+0

¿Está hablando de usar su página principal en HTTP simple e incrustación de un iframe que usa HTTPS? – Bruno

+4

No, al contrario: la página principal es HTTPS, el iframe es HTTP simple. He editado la pregunta para aclarar esto. – moogal

+1

Ya hay un [número de preguntas] (http://stackoverflow.com/search?q=https+iframe) sobre esto. En orden, es una mala idea, porque los usuarios no podrán saber qué parte de la página es segura y cuál no. – Bruno

Respuesta

22

Si se está accediendo a su página utilizando https://www.example.com/main/index.jsp (SSL) a continuación, el navegador se quejará con "esta página contiene elementos seguros e inseguros" si hay recursos en el código HTML que se hace referencia con http:// (no SSL) . Esto incluye iframes.

Si su página de navegación se encuentra alojado en el mismo servidor, entonces puede evitar que el mensaje "contenido no seguro" mediante el uso de una dirección URL relativa así ...

<iframe src="/app/navigation.jsp" /> 

Desde su pregunta Parece que su página de navegación que se sirve de un host independiente y que está siendo forzado a usar algo como esto

<iframe src="http://otherserver.example.com/app/navigation.jsp" /> 

que, por supuesto, el mensaje "contenido no seguro" en su navegador.

Sus únicas soluciones son o bien

  1. implementar SSL en el servidor de la celebración de su página de navegación para que pueda utilizar https:// para su referencia iframe o

  2. el programa de navegación en el mismo servidor para que pueda usar una URL relativa.

Personalmente no puede ver por qué su navegación sería en un host diferente, porque entonces usted va a conseguir problemas de secuencias de comandos entre dominios de JavaScript (a menos que algún JSONP enrrollado está involucrado).

+15

Integración con un tercero, donde no puede ejecutar su código, es un buen ejemplo de cuándo necesitaría una mejor opción que esta. – freyley

+2

¿El enfoque 'src ="/app/navigation.jsp "' no requiere que los contenidos del iframe estén disponibles bajo HTTPS? Sin embargo, de acuerdo con el OP, el iframe está en HTTP simple. – KajMagnus

+0

otro ejemplo es si desea permitir a los usuarios iframe URL arbitrarias. Por ejemplo, en un sitio de diseño de sitio web. – Thayne

35

Si su página es http, entonces permite iframe con contenido https.

Pero si su página es https, entonces no permite el contenido http.

Permite anotar las siguientes posibilidades.

page - iframe - status 

http - http - allowed 
http - https - allowed 
https- http - not allowed 
https- https - allowed 
+3

https - https - permitido - confirmado en [sc2vault.com] (http://www.sc2vault.com/) – bradleygsmith

+3

https - https - scripts inseguros - no permitido – coderek

+3

https - https - imágenes inseguras - permitido – coderek

-1

intente eliminar el http: caracteres en el valor del atributo src como tan:

<iframe src="//example.com/thefile.htm"></iframe> 

Esto es por supuesto una solución, la seguridad es importante, así que no pasar por alto alegremente, pero de todos modos esta vez tiene yo pasado un problema similar.

+14

esto no resuelve el problema. simplemente le dice al navegador "seguir adelante y usar el protocolo que utilizó para acceder a esta página". en este caso, es equivalente a "https: //example.com ..." lo cual no resuelve el problema de que example.com solo esté disponible a través de http –

+1

El uso de esta técnica resolvió mi problema cada vez en cada navegador cuando este tipo de solución provisional se necesita temporalmente – bastien

+0

Como señaló @RobertLevy, esto no "resuelve" el problema. En realidad, es una buena práctica y la mejor forma de usar el protocolo que el padre esté usando. Esto, por supuesto, solo funciona, si el recurso relevante también admite 'https' y' http' – nuts

Cuestiones relacionadas