¿Cómo minimizar el riesgo de datos confidenciales en archivos temporales en un entorno de alojamiento compartido antes del cifrado?

Navega tus respuestas
1

openssl_pkcs7_encrypt() requiere que los datos estén encriptados para ser leídos desde un archivo y, por lo tanto, desafortunadamente requiere que los datos confidenciales se escriban en el archivo temporal antes de que se encripta.

En un entorno de alojamiento compartido, ¿qué pasos puedo seguir para minimizar el riesgo de que los datos confidenciales se lean / roben cuando tenga que escribirlos momentáneamente en un archivo temporal?

El código: 

$file = tempnam(sys_get_temp_dir(), 'mail');
file_put_contents($file, $body);
$encrypted = tempnam(sys_get_temp_dir(), 'encrypted');
if (openssl_pkcs7_encrypt($file, $encrypted, "cert.pem", NULL)) {
    @unlink($file);
    $body = file_get_contents($encrypted);
    @unlink($encrypted);
} else {
    @unlink($file);
    @unlink($encrypted);
}

Las pocas cosas que me preocupan son:

  • sys_get_temp_dir() dependiendo del entorno / host, esto puede variar.
  • ¿Llamar a file_put_contents($file, ""); antes de que @unlink($file) haga una diferencia?
  • Me imagino que un throw…catch alrededor de todo con @unlink calls también ayudaría
pregunta Prembo 21.01.2014 - 16:25
fuente

3 respuestas

3

Si no controlas el hardware, el riesgo es enorme, no importa lo que hagas. Los valores podrían extraerse directamente de un volcado de memoria si alguien realmente quisiera. Incluso si logra hacer que el archivo temporal exista solo por un breve período de tiempo, debe preocuparse por eliminarlo de forma segura, ya que la eliminación de un archivo no borra los datos, simplemente marca el espacio como disponible. De hecho, probablemente sea más peligroso eliminar el archivo, ya que los sectores estarán disponibles para que otro usuario los capture. Usted debe confiar en el proveedor de alojamiento para proporcionar el aislamiento y asegurarse de limpiar el archivo de forma segura una vez que haya terminado con él.

    
respondido por el AJ Henderson 21.01.2014 - 16:39
fuente
2

Si puede permitirse tener su "servicio seguro" dentro de un alojamiento compartido, estoy seguro de que puede permitirse tener una copia temporal de texto claro mientras lo está cifrando.

Si eventualmente necesita un enfoque más restringido y seguro, tendrá que pensar en poseer su hardware.

    
respondido por el kiBytes 21.01.2014 - 16:55
fuente
2

Si se supone que el atacante es el host web, el juego ha terminado.

Suponiendo que su atacante es otro script PHP que se ejecuta en la misma instancia de Apache. A menos que esté ejecutando setUID como usted mismo, entonces todos los servidores virtuales se ejecutarán como usuarios de Apache y podrán acceder a los archivos temporales de cada uno.

Para resolver esto, necesita ejecutar su propia instancia del binario de PHP y configurar su .htaccess para usar eso en lugar de mod_php (lo que tal vez ni siquiera sea posible, no soy un experto en apache).

Alternativamente, puedes usar suPHP, mod_suid2, mod_ruid o similar.

Si realmente no tiene otra opción, al menos haga que los nombres temporales de sus archivos sean un poco más aleatorios, utilizando mt_rand() para generar la raíz.

Pero en realidad, si la seguridad es una preocupación, al menos debería buscar su propio servidor virtual.

    
respondido por el Ben 21.01.2014 - 17:23
fuente

Lea otras preguntas en las etiquetas

¿Qué seguridad ofrece un ISP a sus clientes? ASA5505 DMZ problema [cerrado]