envío de formulario de procesamiento PHP, ¿cómo puedo proteger mejor la información confidencial enviada a través del formulario?

3

Estoy usando PHP 5.6 en Apache 2.4

Tengo un formulario que recopilará información confidencial sobre el usuario que debe cifrarse. Mi solución actual toma la información confidencial de la POST e inmediatamente la encripta de forma asimétrica con una clave pública antes de almacenarla en la base de datos. Usaré SSL en el sitio.

Mi plan es recuperar la versión encriptada y descifrar localmente ya que la información es necesaria, y cuando los datos no sean necesarios, la eliminaré por completo.

Me preocupa que si el servidor se ve comprometido y un pirata informático es capaz de saber que está sucediendo lo anterior, existe la posibilidad de que el pirata informático escriba un script para recopilar los datos de la POST antes de que pueda procesarlos y vaciarlos.

He investigado el cifrado de la información antes de que se envíe el formulario a través de JavaScript, pero me preocupa la carga de CPU / memoria que causaría en el navegador.

¿Hay formas mejores de asegurarse de que en ningún momento alguien, a través de un script inyectado, pueda acceder a los datos de POST? ¿O simplemente estoy siendo extra paranoico?

Clarificación:

Estoy cifrando la información confidencial con claves públicas / privadas RSA 16,384 bit. El tamaño promedio del bloque de información es más cercano a 8000 bits, pero el bit de 16,384 permite casos de uso extremos.

Solo la clave pública está en el servidor, proceso la información en una matriz JSON y luego uso la función openssl_public_encrypt() de PHP. Luego almaceno el bloque cifrado en MySQL.

Al descifrar la información para uso, descargo el bloque cifrado a través de un portal de administración seguro (HTTPS, token CSRF, comparación de contraseña de hash reciclada de una manera) y descifro utilizando una biblioteca basada en JavaScript en mi máquina local.

Este es mi peor escenario

Antes de este proyecto, habría estado de acuerdo con la opinión de que si un pirata informático está en mi sistema, tengo problemas más grandes. Sin embargo, un hacker que rastrea esta información antes del cifrado es exactamente el mayor problema que tengo. No es CC # s, estoy manejando eso a través de Stripe y 100% compatible con PCI.

Sin embargo, tendría una responsabilidad igual, si no mayor, si se comprometiera esta información.

Es por eso que estoy yendo a extremos como manejar el descifrado localmente. He leído los conceptos básicos de cumplimiento de PCI, de modo que la información confidencial debe cifrarse en el tránsito y en el almacenamiento, pero parece que hay un vacío durante el procesamiento, incluso allí. Si me equivoco allí, señale la documentación para poder educarme mejor.

    
pregunta Practically 20.10.2015 - 05:34
fuente

2 respuestas

1

No utilice una nueva solución, reutilice lo que otros ya han pasado. Un buen lugar para comenzar es OWASP .

Para el transporte, use SSL y no administre algún tipo de cifrado en el navegador.

Una vez que los datos lleguen a su servidor, evalúe si desea almacenarlos cifrados y qué riesgo desea evitar exactamente al cifrarlos. Esto impulsará la arquitectura de encriptación (¿prevención de robo físico? ¿Prevención de acceso de administrador? ...).

Y luego, la clave absoluta es asegurarse de que su aplicación esté codificada correctamente. El enlace OWASP anterior le indicará casos genéricos y soluciones de implementación específicas (por ejemplo, para PHP)

    
respondido por el WoJ 20.10.2015 - 12:32
fuente
0

Si siguió los métodos de seguridad para configurar los formularios ( Guía de seguridad de PHP: Procesamiento de formularios ) y así lo hizo. Además, lo que mencionó anteriormente (criptografía pública + HTTPS) ya está bien.

Pero en cuanto a:

  

Me preocupa que si el servidor se ve comprometido y un pirata informático es capaz   de saber que lo anterior está sucediendo, hay una oportunidad para el   hacker para escribir un script para recopilar los datos POST antes de que pueda procesar   y vaciarlo.

Si llegas a la situación en la que tu servidor está comprometido, tendrás que preocuparte por cosas más serias que solo qué hacer para evitar que el atacante recopile los datos de la POST.

Le sugiero que diga cómo administra la (s) clave (s) de cifrado en términos de dónde la almacena / ellos y si utiliza o no la misma clave para descifrar para todos los usuarios o si usa una clave por usuario (aunque creo que trabajas con la primera opción), después de eso, editaré esta respuesta. Es mejor tener una actitud paranoica que no me importa.

    
respondido por el user45139 20.10.2015 - 08:43
fuente

Lea otras preguntas en las etiquetas