Recopilación de información de tarjeta de crédito en iframe HTTPS dentro de un sitio HTTP

Advertencia, IANAQSA

Actualización: Slate no es en realidad un SAQ A: no están usando iframes, y están enviando información de la tarjeta, por ejemplo, enlace ... la mayor parte de lo que se muestra a continuación todavía se aplica en espíritu.

  

¿Alguien podría decirme si es posible obtener de manera segura la información de la tarjeta de crédito de la forma que se describe?

Sí, es posible. Sin embargo, hay una responsabilidad implícita asignada a usted para verificar que su conexión sea segura y que el sitio de pago al que ingresa sea un procesador de pagos legítimo.

Dicho esto, esta configuración es aceptable (según PCI) y ligeramente desaconsejable (según las mejores prácticas de seguridad).

Una lectura de SAQ A, que se aplica a los comerciantes que subcontratan todo el manejo de la tarjeta a su procesador a través de un iframe, sugiere que esta es una configuración legal. Tenga en cuenta que no establece ningún requisito explícito en las páginas que contienen la página de pago (iframe) que contiene las páginas de pago del Proveedor de Servicios; solo las páginas del SP provienen del SP y el SP es compatible con PCI DSS (lo que implica cifrado):

Ahora,dichoesto,hayproblemascomo MITM que hacen que la falta de Encriptación externa por pizarra no aconsejable. Muchas organizaciones se han abierto camino a través de esta joroba y, finalmente, decidieron que cifrar todo en su sitio era preferible a lidiar con la percepción de la inseguridad. Pero generalmente toma tiempo y quejas antes de que las organizaciones lleguen allí. Así que siéntete libre de quejarte de esto.

Lo que están haciendo es ciertamente mejor que no hacer https en absoluto. Sin embargo, su página http externa es más susceptible a ataques como Man-In-The-Middle que podrían hacer que el iFrame 'seguro' sea reemplazado o comprometido de otras maneras. Este método también dificulta a los usuarios finales hacer sus propias determinaciones: el ícono de bloqueo es útil y los navegadores están trabajando arduamente para enseñar a los usuarios cómo determinar si un sitio es seguro.

Teniendo en cuenta el costo mínimo de https ahora y dada la cantidad de seguridad adicional que ofrece en general, no hay razón para que lo defiendan, solo deberían solucionarlo e ir a https en todas partes.

Cuando cifras todo el sitio, estás protegido contra ataques pasivos, que solo leen el tráfico sin modificarlo, así como contra los atacantes activos, que intentarán obtener información tuya y evitar las medidas de seguridad. Al usar un iframe encriptado, aún está protegido contra atacantes pasivos, porque los datos de pago están encriptados en tránsito. Sin embargo, debido a que la página original no está encriptada, un atacante activo (también conocido como un hombre en el medio) puede reemplazar el iframe seguro con uno que apunta a su propio sitio, lo que puede hacer que se vea idéntico al que se supone que está allí. o simplemente obligue al iframe a cargarse y enviarlo a través de una conexión no segura (siempre que no esté usando HSTS para obligarlo a cargarlo a través de HTTPS). Luego pueden capturar todo lo que ingresa, incluidos sus detalles de pago. Además, no hay avisos en el navegador que le informen que lo que ingresa se está interceptando, porque los marcos no tienen indicadores de protocolo o de origen. Eso significa que la única forma de detectar un ataque como este sería inspeccionar el elemento en el formulario, lo que casi nadie haría.

Usar un iframe HTTPS es mucho mejor que nada, pero sería incorrecto decir que es seguro. Personalmente, nunca ingresaría los detalles de pago en una página que no tiene https en la barra de URL, pero cuando se encuentra en una conexión confiable (también conocida como wifi pública), el riesgo es muy pequeño.

Dado que slate.com está redirigiendo a (aún) slate.com, aunque es un cambio de protocolo de http a https, no califica a slate.com por no tener un entorno de datos de titulares de tarjetas. Sí, existe una mayor seguridad (asumiendo TLS 1.2, por ejemplo) entre el navegador del usuario y slate.com, pero eso es todo.