2010-07-26 8 views
5

Tengo una página https (https://example.com/main.php) que tiene un iframe con un origen no https (http://example.com/inner.php). Ambos archivos están en el mismo servidor: solo se accede a uno con https y el otro no. Necesito la página no https para poder ejecutar javascript en el https página main.php utilizando código como parent.myfunction()Permitir que HTTP iFrame llame a JavaScript en el marco principal de HTTPS

Sin embargo, cuando intento esto, me sale el siguiente error:

Unsafe JavaScript attempt to access frame with URL https://example.com/main.php from frame with url http://example.com/inner.php . Domains, protocols and ports must match.

he puesto document.domain = 'example.com' en ambos archivos y pensé que lo arreglaría, sin embargo, no es así. ¿Hay alguna forma de permitir que el marco ejecute javascripts en el marco principal y viceversa? Si es así, ¿cuáles son las implicaciones de seguridad de esto?

PD: Para aquellos de ustedes que sugerirán simplemente usar https o http para ambas páginas, estoy investigando eso. Sin embargo, debido a los procesos que se producen en la página iframe, esta podría no ser una opción viable debido a problemas de carga del servidor.

Respuesta

5

La "misma política de origen" cubre el protocolo ("http" o "https"), el nombre de host y el número de puerto. Todos tienen que coincidir o perder.

Si la carga de su servidor se vería realmente afectada por tener que aplicar el cifrado a la página , entonces sospecho que tiene otros problemas mucho más graves. En este día y edad, eso realmente no debería ser un problema. Si tiene un sitio de gran tráfico, probablemente deba usar un front-end para hacer SSL de todos modos.

0

No puede hacer acceso entre dominios/multiprotocolo/puerto cruzado con JavaScript. Esto se conoce como "cross domain scripting", que es un problema ya que sin seguridad como esta, podría abrir GMail en un iframe, obtener los cuadros de texto "u" y "p", y tener una información de inicio de sesión de ese tipo.

Lo que pones en tu PS es la única solución real que puedes usar además de usar un servidor de eco ... que sería excesivo.

4

Si fuera alguna vez posible hacer lo que está pidiendo que haga, ningún sitio seguro de SSL estará nunca a salvo.

Déjame describir el problema. Digamos que un usuario, Alice, va a acceder a su cuenta en Paypal.com. Yo, Mallory, estoy entre Paypal y Alice. Cuando Alice accede a Paypal, yo intercepto su solicitud y devuelvo una página que contiene dos cosas: un fotograma con https://paypal.com, y una que contiene una página que pretende ser 'http://my.paypal.com', que yo misma diseñé. El marco HTTPS valida bien porque en realidad proviene de Paypal. El marco HTTP contiene algo de Javascript de mi dispositivo que alcanzará el marco HTTPS, y cuando Alicia ingrese su contraseña, ¡me la enviará!

Así que no, no está bien acceder a contenido seguro desde contenido inseguro, incluso en el mismo dominio.

+0

Su ejemplo no funciona: no es posible usar el dominio "my.paypal.com" porque el _whole_ dominio (con todos los subdominios existentes y no existentes) pertenece a paypal. Entonces, en mi opinión, este no es el motivo de esta restricción de seguridad. La razón es la misma, como si desea cargar cualquier contenido a través de http en un sitio https. – rudi

+1

@Rudolf No creo que hayas entendido completamente lo que dije. El atacante devuelve una página con dos * marcos * dentro de ella. Un cuadro contiene la buena fe https://paypal.com. El otro contiene javascript malicioso. El javascript malicioso "fue entregado desde paypal.com", pero realmente, intercepté la solicitud y devolví el contenido que quería (posible porque no es una conexión segura).Por lo tanto, los dos marcos "pasan el mismo control de origen", pero el resultado es un desastre. – Borealid

Cuestiones relacionadas