¿El formulario de pago de http es seguro? [cerrado]

2

Hay muchas pasarelas de pago (Worldpay, PayPal, ...) que ofrecen una fácil integración, cuando la página web simple utiliza la redirección de URL a la página de pago. HTTPS (worldpay, paypal), donde el usuario publica los detalles de su tarjeta y los datos de pago, están encriptados y son de confianza.

Hay dos páginas web HTTP y HTTPS (seguras) para pago. El usuario de la página HTTP no encriptada es redirigido a la página HTTPS, utilizando una URL de redireccionamiento como: enlace

La página HTTPS se abre al usuario desde una página HTTP normal, haciendo clic en un botón que abre una nueva URL. La cadena de URL con sus parámetros viaja como texto sin formato al sitio HTTPS. El parámetro de URL contiene la ID del comerciante y la cantidad.

El HTTPS (worldpay) muestra todos los datos que se envían a través de url (por lo que si el ataque MITM cambiara, se mostrarían los datos modificados) y el usuario ingresa los detalles de su tarjeta allí. Esta página de destino está encriptada, y el usuario puede verificar los detalles del pago. Como pagar por quién, cuál es el monto, etc.

La pregunta es, ¿es seguro?

Para los comentarios, trato de volver a editar y aclarar más. 2015-04-17 EDITAR: "suficientemente seguro" = es confiable, y usted puede pagar sin el riesgo de que un hacker le robe su dinero. No estoy seguro, no es un truco fácil para engañar a ese tipo de sistema. Por cierto Esta es la forma sugerida por las compañías de pasarela de pago de terceros (paypal, worldpay).

enlace Dice: "Todo el procesamiento de pagos es manejado por el servidor seguro de WorldPay, por lo que usted y sus compradores pueden estar seguros de que sus detalles de pago están seguros".

support / kb / bg / pdf / rhtml.pdf "Las ventajas son que casi todos los navegadores admiten cadenas URL, y son fáciles de codificar y usar. Sin embargo, dado que el destinatario puede ver todos los atributos y valores en la cadena URL, puede que no se sienta seguro".

    
pregunta oupse1234 15.04.2015 - 16:35
fuente

2 respuestas

1

Se puede confiar en una configuración de este tipo, ya que su pirata informático no puede extraer los detalles de pago y los detalles de pago pueden verificarse de forma segura.

Lo que hay que tener en cuenta es que muchos usuarios no se molestan en volver a verificar los detalles en la página https, o si hay parámetros "ocultos" enviados que no se muestran y verifican explícitamente.

    
respondido por el Up Here 16.04.2015 - 00:19
fuente
1

"Lo suficientemente seguro" y "de confianza" son frases de riesgo.

Si está hablando de transmitir un número de tarjeta de crédito, una dirección de correo electrónico, un SSN u otra información personal no cifrada como texto sin formato a través de un parámetro de URL, entonces esto definitivamente no es seguro, independientemente de a dónde vaya. La página debería ser una página cifrada para que esa información se cifre en tránsito. Si no lo es, entonces cualquier persona en el medio con un oyente pasivo podría recoger esa información.

Si estás en una zona de pruebas, puedes abrir un rastreador de paquetes (como wireshark) y ver qué se está transfiriendo realmente.

Si la página que captura (contiene el formulario) la información confidencial está encriptada, es probable que esté bien.

  1. En el certificado querrá verificar el nivel que están usando para la autenticación, es decir, cuántos bits de cifrado.
  2. Querrá asegurarse de que el certificado que están usando esté realizado por una Autoridad de Certificación de terceros adecuada para que no sea fácil de falsificar.
  3. Lo ideal sería que el sitio tuviera su propio certificado que encripta la conexión para el resto del formulario.

Si una página no segura está cargando elementos de una página segura, entonces pueden existir riesgos con tener contenido no seguro con respecto a Javascript u otras capacidades de scripting del lado del cliente. Si, por ejemplo, un Javascript está comprometido en esa página, entonces en teoría puede capturar los datos de un formulario utilizando escuchas de eventos algo como onChange y AJAX antes de que el contenido del formulario se envíe a través de la conexión segura. Javascript también podría permitir un ataque de hombre en medio que raspe los contenidos en la transmisión a través de un controlador como onSubmit . Esto realmente depende de si el sitio en sí es lo suficientemente "seguro" para no permitir ataques de inyección y cosas por el estilo.

A menudo la gente no piensa en cosas como anuncios de banner que a menudo ejecutan Javascript. Un anuncio publicitario puede capturar fácilmente los datos de cualquier otra cosa en la página, siempre que tenga los mismos permisos. Lo mismo ocurre con los complementos del lado del cliente en función del navegador.

    
respondido por el AbsoluteƵERØ 16.04.2015 - 01:35
fuente

Lea otras preguntas en las etiquetas