Página de pago hospedada - Implementación de la perspectiva de seguridad

1

Estamos implementando una aplicación .NET MVC y planeamos utilizar una página de pago hospedada para pagos seguros y desde el punto de vista de PCI.

Me preocupa la información sobre los datos que podríamos exponer en la llamada de retorno y buscar algunas de las mejores prácticas de implementación.

Estoy planeando hacer esto según la expectativa de flujo de la página de pago hospedada

En nuestra aplicación MVC tenemos una página de ventas donde el usuario agrega la cantidad, los comentarios y otros campos obligatorios y envía

después de validar la configuración de los campos requeridos junto con la URL de devolución de llamada que redirige al usuario a la página de pago alojado de un proveedor diferente

Una vez que se complete la transacción, la página de pago alojado Devolver mi URL de devolución de llamada que es uno de los puntos finales en MVC

En la URL de devolución de llamada (acceso anónimo) , básicamente, estoy decodificando el resultado que compartieron en la cadena de consulta y llamando a su API para decodificar y mostrando los resultados finales al usuario en la misma página de ventas (protegido) (donde suceden 302, 200 redirecciones de url de devolución de llamada (Anónimo) a la página de ventas (Asegurado))

Mi página de ventas está protegida, pero mi URL de devolución de llamada está expuesta. Por lo tanto, mis preguntas están exponiendo la página de ventas a la página de pago alojada o cualquier problema de seguridad al hacer esto.

Verifiqué esto en Fiddler. Si no eres usuario registrado, serás redirigido a la página de inicio de sesión. ¿Cuál es el riesgo de seguridad que conlleva mi implementación actual de exponer mi URL de devolución de llamada y la URL de devolución de llamada redirigir internamente a una acción diferente?

¿Cuáles son los mejores elogios para manejar esto? Por favor comparte tus ideas

    
pregunta Peru 18.05.2018 - 17:28
fuente

1 respuesta

1

Resumiendo mi comprensión basada en preguntas y comentarios:

  • Estás utilizando PxPay 2.0 de Payment Express
  • Está utilizando el método de redirección (a diferencia de Iframe)
  • Espera que el navegador del cliente vuelva a usted a través del UrlFail / UrlSuccess que especifique
  • Espera que Payment Express también le notifique el estado a través de UrlFail / UrlSuccess
  • Su preocupación es si la información confidencial se puede enviar a UrlFail o UrlSuccess, y se expondrá por falta de cifrado

Aunque no está definido explícitamente, todos los ejemplos en la PxPay 2.0 Integration Guide muestran que todas las llamadas al Las URL de UrlFail / UrlSuccess incluyen dos parámetros, result y userid :

Elresultsedescribecomolanecesidaddeser'descifrado',perocomoelprocesodedescifradoesbuscarelsignificadoconotrallamadaaPaymentExpress,escasiseguroqueessolountokendesesiónsincontenidosemántico,ynoesútilacualquierpersonasinsuscredencialesdecuentadePaymentExpress.

EluserideslapartedelnombredeusuariodelascredencialesdesucuentadePaymentExpress.Sibienseríapreferiblemantenereste"secreto" y, por lo tanto, HTTPS sería mejor, tenga en cuenta que atraviesa el navegador del cliente durante el proceso de redireccionamiento y, por lo tanto, es vulnerable a ser divulgado, y su secreto no es un requisito de seguridad. / p>

Por lo tanto, diría que se prefiere el cifrado para UrlFail y UrlSuccess, pero no es necesario; no hay información allí que, de lo contrario, no esté protegida por la necesidad de contar con las credenciales adecuadas para acceder a él.

    
respondido por el gowenfawr 21.05.2018 - 21:40
fuente

Lea otras preguntas en las etiquetas