Necesito ayuda para enumerar los riesgos específicos de incrustar un iframe HTTPS que permita el pago con tarjeta de crédito dentro de una página HTTP. ¿Hay problemas de seguridad? ¿Con incrustar un iframe HTTPS en una página HTTP? proporciona algunas preocupaciones de alto nivel, pero estoy buscando ser lo más específico posible sobre posibles vectores de ataque. Haga clic en Buy Now para obtener un buen ejemplo de un iframe seguro dentro de una página insegura, que se utiliza Hoy para transacciones con tarjeta de crédito. Esto es lo que tengo hasta ahora:
- La conversión probablemente será menor porque los usuarios informados sabrán que no deben ingresar el número de su tarjeta de crédito sin ver un candado verde en la URL en el navegador de Google Chrome. (Es posible que los usuarios menos informados no sepan que no deberían confiar en el bloqueo que aparece dentro del marco del navegador, como se muestra en el ejemplo anterior).
- Incluso si los usuarios se sienten cómodos con este enfoque, generalmente es una mala idea animar a los usuarios a ingresar su número de tarjeta de crédito cuando no ven una confirmación de bloqueo de SSL en la barra de URL. Está enseñando a los usuarios malos hábitos de seguridad. Esta publicación señala que SSL se refiere a la seguridad más que al cifrado. y autenticación.
- Un hombre activo en el medio podría inyectar un script malicioso en la página principal que podría presionar el botón snoop. Creo que esto es lo que hizo el gobierno tunecino para robar disidentes Credenciales de Facebook. (Creo que el script malicioso no podrá acceder al nombre de usuario y contraseña desde el iframe seguro, pero aún podría acceder a las pulsaciones de teclado). Por supuesto, una autoridad gubernamental más determinada podría subvertir el DNS y falsificar también un certificado SSL, como gobierno iraní aparentemente lo hizo, en cuyo caso una página padre segura no ayudaría.
También tengo esta lista de preocupaciones poco realistas:
- Otro objeto de Javascript en la página principal no segura podría husmear el contenido del iframe seguro. Creo que esto ya no es posible siempre y cuando solo se admitan los navegadores IE8 y superiores.
- Un objeto rogue de Javascript en la página principal podría realizar el registro de pulsaciones de teclas para capturar el número de tarjeta de crédito de un usuario. Esto puede ser posible, pero el riesgo no se ve afectado por la publicación de la página principal a través de SSL o no. Una secuencia de comandos no autorizada podría presionar el botón snoop de cualquier manera.
- El usuario no puede ver la URL desde la cual se sirve el iframe seguro. Con una página principal segura o insegura, deberías ser un usuario técnicamente sofisticado para ver la URL de la fuente del iframe.
¿Podría decirme qué otras vulnerabilidades realistas e irreales me faltan? No tengo ninguna duda de que la mejor opción es siempre incrustar un iframe seguro en una página padre segura. Lo que estoy tratando de decidir es los riesgos y beneficios relativos de habilitar un iframe seguro dentro de una página insegura en comparación con la mala experiencia de los usuarios al saltar del sitio inseguro en el que ven el producto para completar un proceso de pago seguro en otro lugar.