PCI Compilance - Procesador de pago personalizado

En lo que respecta a PCI-DSS, cualquier sistema que toque (no almacena, no procesa, sino toca) o CAN TOUCH (es decir, en el mismo segmento de red que un sistema que toca) debe ser compatible con PCI-DSS. El servidor A está tocando claramente a PCI y es casi seguro que debería ser compatible.

Al realizar una redirección con token, soluciona el problema porque el usuario no ingresa los detalles de PCI en su sitio y sus sistemas nunca manejan los datos de PCI. Todo lo que envía es los detalles sobre lo que se debe cobrar y luego recuperar un token que es efectivamente el recibo del pago. Dado que ninguna de estas piezas de información es PCI y usted no tiene una conexión de red física directa con la pasarela de pago, el escaparate no debe estar bajo PCI en el momento de escribir este documento (hasta donde sé, no soy abogado ni estoy involucrado activamente con el cumplimiento de PCI en este momento).

En cuanto al caso que describió sobre un registrador de teclas que compromete la seguridad, PCI-DSS es un estándar de seguridad de datos para proteger PCI en el lado del servidor / proveedor. Un exploit del lado del cliente sería un cliente comprometido y está en el extremo del cliente, por lo tanto, está fuera del alcance de PCI-DSS. Esta es la razón por la que si el usuario recibe un virus de usted antes de redirigirlo, no compromete el cumplimiento de PCI de PayPal, ya que el virus proviene de un sistema no cubierto y está en el lado del cliente. No es un compromiso de PayPal, solo un compromiso de un sitio aleatorio que no necesita ser compatible con PCI, lo que lleva a una máquina cliente comprometida.

Como anterior PCI QSA, mi opinión es no. Con los detalles disponibles, parece que el Servidor A se consideraría parte del entorno del titular de su tarjeta, ya que las transacciones con tarjeta de crédito se transfieren a través del POST. En esta situación, no cumpliría con el Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros, y el Requisito 11: Probar periódicamente los sistemas y procesos de seguridad.

No, no es compatible con PCI.

¿Por qué? Porque "A" es la parte de la cadena de procesamiento de información del titular de la tarjeta. En este caso, "A" es una parte esencial de su POS basado en IP.

- En el primer caso: Rompiendo PCI-DDS 6.5 (específicamente 6.5.7) [Página 42]

  

Podemos solicitar los detalles de la tarjeta de crédito en el servidor A y enviarlos por POST   al servidor B

Esto es sencillo, "A" comprometido = información del titular de la tarjeta comprometida . Un atacante puede inyectar código malicioso (generalmente JavaScript) para robar la información del titular de la tarjeta.

- En el segundo caso: Rompiendo PCI-DDS 6 [Página 38 ]

  

Podemos solicitar los detalles de la tarjeta de crédito en el servidor B mediante iframe y enviar   vía POST al mismo servidor

Afortunadamente, gracias a la Política del mismo origen , el atacante no puede acceder al contenido de el iFrame servido por "B" usando scripts en una página servida por "A" (supongo que los tiene en dos dominios diferentes).

Pero, si el atacante tiene acceso a "A", entonces puede utilizar las vulnerabilidades de Java o Flash para instalar malware / keylogger en la máquina del cliente, lo que puede comprometer la información del titular de la tarjeta. Otra posibilidad es engañar al usuario para que instale voluntariamente algunos programas maliciosos disfrazados como un complemento requerido / recomendado o "software de seguridad del banco".