Tengo una solicitud de un cliente que desea que uno de sus formularios existentes esté presente en otro sitio web.iframe un formulario SSL seguro en un sitio que no sea SSL
Quisieran tener un formulario de pago presente en un iframe.
¿Qué implicaciones hay, si las hay, al realizar un cambio en un sitio web SSL en un sitio web que no es SSL cuando se trata de pagos?
El navegador de los usuarios les dará advertencias de seguridad que básicamente dicen que este es un escenario inseguro. Por ejemplo, un ataque man-in-the-middle podría inyectar javascript en su página no SSL y ahora usted está potencialmente comprometido.
En este caso, una página emergente o una redirección de página plana es la forma adecuada de hacerlo. Como probablemente sea consciente, desea que el 100% del contenido de su navegador se aloje a través de SSL en este tipo de escenario. De lo contrario, simplemente no se garantiza que esté protegido. Esa es la razón de esas advertencias.
Eso es lo que pensé. Me acaban de informar que también podemos asegurar el segundo sitio SSL. Eso debería sacarnos de las advertencias de contenido no seguro. Gracias. – Kevin
Los navegadores web modernos no darán ninguna advertencia de seguridad porque la ventana principal se ejecuta de forma insegura a través de HTTP. Sin embargo, la caída es que su navegador web no mostrará un ícono de bloqueo seguro en la barra de direcciones ya que el contenido seguro está dentro de una ventana secundaria (iframe), por lo que los usuarios pueden temer que el formulario no sea seguro.
Un ataque de hombre en el medio es poco probable ya que todos los navegadores web, clásico & moderno, deniega cualquier acceso al contenido de iframe mediante Javascript, ya que el iframe usa un protocolo y/o nombre de dominio diferente. La única forma de comunicarse con el iframe en este punto es a través de la función postMessage implementada en los navegadores web modernos, que permite la comunicación entre dominios a través de Javascript. Incluso si está utilizando postMessage, el iframe debería incluir código que escuche los eventos de postMessage provenientes de la ventana principal, que en el caso de desarrollar un formulario de pago en un iframe, solo la ventana principal deberá escuchar el evento después de el pago es procesado Por lo tanto, es muy poco probable que ocurra un ataque de hombre en el medio si mantiene la comunicación a través de postMessage por un lado (iframe ejecuta solo postMessage y el padre escucha por los mensajes).
Por supuesto, cualquiera podría anular el detector de eventos y ejecutar el código en la ventana principal, engañando al servidor haciéndole creer que se procesó un pago. Es entonces cuando tendrá que tomar precauciones en su código del lado del servidor que verifica para asegurarse de que una transacción realmente sucedió legítimamente. En mi caso, mi formulario de pago (iframe) crea una clave temporal en la base de datos y envía esa clave a la ventana primaria a través de postMessage. Luego, la ventana principal realiza una llamada AJAX al servidor, comprueba la base de datos para ver si coincide con la clave y rápidamente elimina la clave antes de crear un registro de que efectivamente ocurrió una transacción.
@Kevin: Bienvenido a StackOverflow :) Aquí hay una pregunta relacionada que podría apuntar a algunas cosas a considerar: http://stackoverflow.com/questions/2356080/ssl-login-in-iframe –