Formulario de almacenamiento PHP seguro y almacenamiento

8

Estoy creando una aplicación PHP que permite cargar archivos (.doc / pdf, etc.) para que un miembro del personal los revise. Algunos de estos archivos serán algo confidenciales, por lo que debo protegerlos.

Ahora, la mejor solución sería lograr que el remitente cifre estos archivos con GPG o similar antes de cargarlos y descifrarlos con una clave previamente compartida en el otro extremo (en la computadora del personal, no en el servidor web). / p>

Sin embargo, no es realista esperar que todos los clientes instalen y aprendan a usar GPG para cargar archivos.

Así que la mejor solución que puedo encontrar es:

1) Realice cargas de archivos a través de HTTPS en una página protegida por contraseña.

2) Cifre archivos utilizando GPG asimétrico y un archivo de clave pública almacenado en el servidor web.

3) Borre todas las copias no cifradas del archivo en / tmp etc.

4) Envíe un correo electrónico al personal para notificarles que el archivo está disponible para descargar.

5) El miembro del personal inicia sesión y descarga el archivo, el servidor luego borra la copia encriptada.

6) El miembro del personal luego desencripta el archivo usando su clave privada que no está almacenada en el servidor web.

La idea aquí es que siempre que el servidor web esté comprometido (es un servidor dedicado, por lo que no se comparte con otros), el atacante no podrá descifrar estos archivos porque no encontrarán la clave allí.

Sin embargo: creo que esto todavía es vulnerable.

Porque, si un atacante tiene una raíz o solo el control del usuario del servidor HTTP, podrá leer los datos de / tmp mientras el archivo todavía se está cargando / encriptando y hacer una copia sin cifrar que podrá descargar más tarde.

Entonces, ¿quizás podría hacer todo esto en la memoria sin escribir en / tmp? Pero todavía existe el riesgo de que el atacante pueda descubrir las direcciones de memoria en las que se escriben los datos cargando un archivo ellos mismos y luego usar ptrace. para inspeccionar y copiar esas direcciones de memoria.

No puedo pensar en una forma de solucionar este problema, ya que necesitaré los datos en texto sin formato para realizar el cifrado. ¿Hay alguna forma en PHP para hacer que la inspección de memoria sea más difícil? ¿O hay un servicio web de terceros que sería mejor utilizar para esto?

    
pregunta user350325 25.01.2013 - 22:45
fuente

2 respuestas

5
  

Entonces, ¿quizás podría hacer todo esto en la memoria sin escribir en / tmp? Pero todavía existe el riesgo de que el atacante pueda descubrir las direcciones de memoria a las que se escriben los datos al cargar un archivo y luego usar ptrace para inspeccionar y copiar esas direcciones de memoria.

Una configuración SELinux correctamente instalada puede mitigar los riesgos de una máquina comprometida por el control de la aplicación. En última instancia, debe mantener la máquina segura.

  

No puedo pensar en una forma de solucionar este problema, ya que necesitaré los datos en texto sin formato para realizar el cifrado. ¿Hay alguna forma en PHP para hacer que la inspección de memoria sea más difícil? ¿O hay un servicio web de terceros que sería mejor utilizar para esto?

Simplemente no hay forma de evitar la realidad de tener que tener el archivo entrante en un estado de texto claro en la memoria en algún momento del proceso de cifrado. Sin embargo, el cifrado en la memoria es sin duda el camino a seguir.

    
respondido por el Jeff Ferland 25.01.2013 - 23:22
fuente
4

Siempre puedes usar JavaScript en la interfaz del navegador y cifrarlo antes de llegar a la red. Aún debe utilizar TLS para transferir la página web, a fin de disminuir las probabilidades de un ataque MITM que podría cambiar el código de Javascript.

En el extremo del navegador, podría generar claves AES únicas por sesión y luego cifrar las claves AES a través de OpenSSL con la clave del miembro del personal en el backend, por lo que el destinatario podría descifrar la clave simétrica con la suya.

Puedo enviarle MEGA como referencia de un ejemplo de trabajo.

Beneficios :

  • Al usar JavaScript, nunca tendrás el archivo descifrado en la memoria.
  • Al cifrar la clave AES, tendrá tiempos más rápidos.
  • No necesita GPG en el lado del cliente.
  • Las claves son de un solo uso, por lo que tendrían que descifrar tantas claves como documentos.

Cuídate :

  • Las claves deben estar protegidas: no deben escribirse en un almacenamiento permanente antes de pasarlas a través del cifrado OpenSSL (y luego se olvidan).
  • En cualquier señal de ataque, la memoria debe ser una prioridad. Para mitigar las claves AES de un uso robadas, cierre el servidor web en el primer signo y reinícielo nuevamente. El usuario solo verá un poco de tiempo de inactividad.
  • Transferencia de JavaScript y generación y transferencia de claves AES.
  • Una extensión del navegador puede modificar realmente tu JavaScript. Considere empaquetar el JavaScript como una extensión del navegador para tener más control sobre esa parte.
respondido por el ssice 25.01.2013 - 23:24
fuente

Lea otras preguntas en las etiquetas