¿Estas instrucciones de integración del comerciante son incorrectas acerca de la interacción servidor-cliente?

Question

¿Estas instrucciones de integración del comerciante son incorrectas acerca de la interacción servidor-cliente?

#1 de Ilmari Karonen (3 votos)
#2 de Edev444 (0 votos)

2

Estoy trabajando con una pasarela de pago que parece tener un malentendido fundamental de los "clientes" y cómo proteger los datos confidenciales.

Las instrucciones de integración consisten principalmente en un modo de operación de "redireccionamiento", donde un cliente es dirigido al sitio web de la pasarela para ingresar los detalles de la tarjeta de crédito, donde ve un recibo y luego se le dirige a su sitio web.

Docs :

enlace

Aquí hay un ejemplo

<form 
action="https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process
.do" method="POST"> 
<input type="hidden" name="ssl_merchant_id" 
value="my_virtualmerchant_id">
<input type="hidden" name="ssl_user_id" value="my_user_id"> 
<input type="hidden" name="ssl_pin" value="my_pin">
<input type="hidden" name="ssl_transaction_type" value="ccsale">
<input type="hidden" name="ssl_show_form" value="true"> 
<input type="hidden" name="ssl_amount" value="14.95"> 
<input type="submit" value="Click to Order"> 
</form>

Este es el párrafo que me preocupa:

Todos los datos confidenciales, específicamente sus credenciales de VirtualMerchant, deben colocarse en el código del lado del servidor en lugar de colocar campos de valor ocultos en un formulario HTML. Esto limitará la capacidad de los usuarios maliciosos. para editar y utilizar estos datos para sus propios fines fraudulentos. El uso de scripts del lado del servidor permite HTML personalizado para ser entregado a una máquina cliente. El código que genera el HTML personalizado es procesado en el servidor web antes de que el HTML se envíe a la máquina del usuario a través de Internet. Esto es en a diferencia de las secuencias de comandos del lado del cliente en las que se modifica el HTML, normalmente mediante java-script en el cliente máquina después de que el HTML y Java se envían desde el servidor web. La principal ventaja de usar scripts de servidor con la integración de VirtualMerchant es la capacidad de ocultar las credenciales de procesamiento confidenciales desde el navegador.

Eso suena bien, no exponer mi ID de cuenta al cliente.

Sin embargo, no creo que lo que están sugiriendo se ocupe de ello. Solo puedo ver dos formas de ocultar los detalles completamente del cliente:

Haga que el servidor actúe como el cliente y el navegador nunca se dirige al sitio web de la pasarela de pago

Ofrecen este modo, pero la mayoría de los documentos se refieren al modo de formulario HTML / lado del cliente en su lugar.
Use un token firmado de algún tipo , que no son compatibles.

Este párrafo, sin embargo, parece afirmar algo sobre el uso de "scripts del lado del servidor" para entregar "HTML personalizado" y, por lo tanto, ¿ocultar los detalles? Simplemente no veo ninguna manera, incluso si la redirección se realizó a través de un encabezado Location , los datos aún se expondrían al navegador y cualquier persona con intenciones malintencionadas podría obtenerlos fácilmente.

¿Puede alguien ayudarme a entender por qué esto me suena tan mal?

pci-dss web-service

pregunta Nicole 29.06.2012 - 10:40

fuente

2 respuestas

Lea otras preguntas en las etiquetas pci-dss web-service

¿Dónde almacenan las organizaciones sus documentos confidenciales? ¿Cómo los protegen? ¿Cómo protegen los escáneres AV contra el código malicioso cifrado (PGPd)?

score 3 · Answer 1

De un vistazo, parece que las instrucciones en la guía para desarrolladores no son tanto < em> incorrecto como simplemente engañoso. Como puede observar, casi todos los ejemplos muestran los campos sensibles ssl_merchant_id , ssl_user_id y ssl_pin incrustados como campos de formulario ocultos en el código HTML enviado al cliente. Sin embargo, si se abre camino hasta el capítulo 9, "Seguridad de transacciones", encontrará el siguiente párrafo en "Consejos de mejores prácticas" ( negrita original, cursiva mío):

" Código del lado del servidor : sus usuarios pueden leer el código fuente HTML de sus páginas web cuando se descargan en su navegador web. Aunque nuestros ejemplos simples en el documento muestran esto como un método para pasar datos a VirtualMerchant, no recomendamos esto para su producción sitio web. Todos los datos confidenciales de comerciantes, incluidos los montos de transacción y su VirtualMerchant Las credenciales deben colocarse en el código del lado del servidor, en lugar de en campos de valor ocultos en un formulario HTML. Esto reducirá la capacidad de los usuarios malintencionados para explotar la vulnerabilidad del navegador del cliente para editar y utilizar estos datos para sus propios fines fraudulentos. Si no tiene los conocimientos suficientes para implementar esto por su cuenta, hay bastantes proveedores de carritos de compras que proporcionan este servicio de forma inherente y son compatibles con VirtualMerchant ".

Básicamente, es un caso de "haz lo que te digo, no como yo (te muestro cómo hacerlo)".

Dicho esto, me parece que, si sigue cuidadosamente todas las recomendaciones de seguridad de otro , es posible que no se le pase el ID del comerciante / usuario y el PIN al cliente. Ser tan malo como pueda parecer. Bien hecho, tener esos valores solo debería dar al cliente acceso a una cuenta de usuario limitada que solo les permita hacer pagos a usted, pero eso es lo que les está permitiendo hacer de todos modos, por lo que debería ser no es gran cosa.

Por supuesto, eso solo es válido si realmente puede (y lo hace) hacer que la cuenta de usuario utilizada para el formulario sea tan limitada que sea seguro entregarla a los clientes. Sin más estudios, realmente no puedo decir si eso es posible o no.

score 0 · Answer 2

He estado trabajando con pasarelas de pago durante algún tiempo y esto puede ser un poco confuso.

Primero, la segunda declaración hecha por Elavon en el capítulo 9, "Seguridad de transacción" dice que el código del lado del servidor ".. reducirá la capacidad de los usuarios malintencionados de explotar la vulnerabilidad del navegador del cliente para editar y utilizar estos datos para sus propios fines fraudulentos ".

La declaración anterior es correcta, ya que reducirá el conocimiento técnico necesario para obtener acceso a estas credenciales. En lugar de que un cliente haga clic en la fuente de la vista y vea los datos de la publicación, necesitarían usar fiddler o similar para capturar la información de la publicación. En cualquier caso, esta es una vulnerabilidad inherente de esta arquitectura. Antes de 2008, la mayoría del procesamiento de CC se realizó como una llamada de API de servidor a servidor, lo que puede resultar en un sistema comprometido que recopila miles de números de CC, datos de usuario, etc. Esta arquitectura permite una fácil manipulación de datos de 1 a 1, lo que significa que cada cliente Puede cambiar y recopilar fácilmente estos datos, pero no a gran escala. La regulación de cumplimiento de PCI también supondrá una gran carga para su organización si completa las transacciones de servidor a servidor.

Lo que debe hacer para mitigar cualquier compromiso potencial:

Asegúrese de crear un usuario no administrador para completar estas transacciones.
DEBE reconciliarse todos los días con el proveedor de pagos. Para hacer esto, puedes usar la API para conectarte con el proveedor de la pasarela de pago y obtener TODAS las transacciones liquidadas por los últimos x días (hago 7). Recorra cada lote y verifique cada transacción para verificar la precisión entre ambos sistemas (el suyo y la pasarela de pago). He creado una sofisticada rutina de reconciliación que envía correos electrónicos al personal de TI y a nuestra oficina de seguridad si algo no coincide correctamente. Puede tratarse de un usuario que cambia el importe de la facturación utilizando Fiddler o manipulando el resultado de la transacción. Recuerde, tanto la publicación de la transacción como el resultado pasan por el cliente con algunas configuraciones y no puede confiar en que el cliente sea "veraz". Si está creando un sistema que envía mercancía física, debe esperar hasta que la transacción se liquide y se haya reconciliado antes de enviar el producto por correo para evitar fraudes y abusos.

El compromiso de las claves de transacción no significa mucho, ya que el actor malintencionado enviará dinero a su cuenta bancaria y nadie quiere hacerlo. Debe asegurarse de que sus credenciales de inicio de sesión en la consola de administración no estén comprometidas y no veo que esto pueda suceder en un entorno seguro.

Sin embargo, debe crear un nuevo usuario independiente de uno utilizado para procesar las transacciones para conciliar con el proveedor de la puerta de enlace. Con el usuario que creó para procesar transacciones, DEBE desactivar el acceso a la API para conciliar. Si alguien obtiene acceso a sus credenciales de usuario de conciliación, puede escribir el código de conciliación utilizando esas credenciales y obtener un volcado de todos sus clientes junto con los montos de compra y todo tipo de datos como el nombre, la dirección, etc.

Mejor de la Suerte, Eric