La misma información confidencial en la respuesta HTML que se publicó antes

4

¿Es un problema devolver la misma información confidencial (PCI, PII) del servidor en la respuesta HTML que un usuario publicó anteriormente en el servidor?

En nuestra página web, el usuario ingresa cierta información clave (nombre / dirección / tarjeta / número de cuenta / etc.), que luego se publica en nuestro servidor y le enviamos una página con información no confidencial (fechas, cuenta balance, etc.) junto con la información clave que acaba de proporcionar, de modo que el usuario pueda cambiar algunos valores clave para modificar la búsqueda.

Ejemplo:
POST al servidor: ...&cardNumber=1111222233334444&...
Respuesta del servidor: <html> ... <input name="cardNumber" value="1111222233334444" ... /> Here are some details about your card... </html>

El sitio web recientemente se sometió a una evaluación de seguridad en la que el revisor señaló este comportamiento como una vulnerabilidad de alta prioridad, por lo que no debemos devolver ninguna información confidencial no enmascarada en la respuesta HTML del servidor ( value="111122223333444" en el ejemplo anterior). Mencionaron el ataque MITM, donde alguien puede robar información confidencial de los datos HTML.

Los desarrolladores desafiaron esto diciendo que el MITM puede robar datos de ambas formas de tráfico, por lo que el MITM podría robar los datos del mensaje POST y el servidor no está enviando datos más confidenciales de lo que se envió originalmente al servidor. Y proporcionaron algún rastro de red que muestra algunos sitios web bien conocidos en Internet que también realizan esta práctica.

¿Quién tiene razón: el revisor de seguridad o los desarrolladores, y por qué?

Tenga en cuenta que solo se puede acceder al sitio web a través de HTTPS y otras medidas de seguridad (control de caché, caducidad de página, etc.) también implementadas.

    
pregunta Tamás Somogyi 25.10.2017 - 14:25
fuente

2 respuestas

1

Sus desarrolladores tienen razón. Si se usa HTTPS desde el cliente al servidor que procesa la solicitud, la conexión debe ser igual de segura en ambas direcciones. Si ambas comunicaciones están en la misma sesión SSL, se debe esperar que la clave utilizada para el cifrado real sea idéntica.

Sin embargo, se plantea la pregunta de por qué haces esto? Si el cliente acaba de enviar los detalles de la tarjeta, ¿por qué es necesario enviarlos nuevamente en el HTML? ¿No se puede manejar esto con JavaScript en el extremo del cliente?

Tampoco estoy completamente familiarizado con los estándares de seguridad de datos de PCI, pero esto puede infringirlos. Sé que para los recibos hay límites.

La guía para hacer y no hacer lee -

  

Asegúrese de enmascarar PAN cada vez que se muestre. Los primeros seis y los últimos cuatro dígitos son el número máximo de dígitos que se pueden mostrar.

Para mí, enviar esto en HTML es una forma de mostrarlo. También existen riesgos adicionales relacionados con el código malicioso en el cliente.

    
respondido por el Hector 25.10.2017 - 14:49
fuente
0

Depende: lo que dice el revisor es incorrecto si se pasa por TLS. Pero el problema aquí (corríjame si me equivoco) es que la página web ahora tiene información confidencial incrustada.

Entonces, si se encuentra una falla adicional como XXS, esta información confidencial se puede extraer de la estructura HTML. El usuario ahora tiene una copia en caché de los detalles de su tarjeta de crédito en su máquina. Si se trata de una máquina compartida, también se pueden extraer.

Sí, deberías arreglar esto.

    
respondido por el McMatty 24.01.2018 - 01:05
fuente

Lea otras preguntas en las etiquetas