Riesgos de seguridad al usar tmpfile () para datos confidenciales en PHP

1. Se debe asumir que los datos se vacían cuando se escriben en un archivo. En teoría, podría permanecer en los buffers y nunca ser desechado, pero no puede confiar en eso y no tiene forma de saber si lo hizo. La ubicación del archivo temporal podría ser un disco montado en RAM (como tmpfs en Linux), pero probablemente no tenga acceso a esa información y, de nuevo, no puedes confiar en que ese sea el caso. El peor de los casos (y el más probable) es que se escriba en el disco duro, en cuyo caso cualquier persona con privilegios de lectura de disco sin formato, como el administrador, podría buscar en los sectores sin procesar del disco duro y examinar los datos. Esto no es tan difícil como parece, he recuperado archivos de texto eliminados antes de usar un simple encadenamiento de las herramientas NIX dd y grep .

2. No creo que sea un problema. El archivo creado a partir de tmpfile() debe eliminarse automáticamente al cerrar el archivo, independientemente de dónde se haya creado. (Al menos, eso dice el manual y la experiencia.)

3. Claro. El administrador podría monitorear el directorio temporal y hacer una copia de cualquier archivo que vea creado. Esto debería ser factible en el nivel de modo de usuario, y ciertamente es factible en el nivel de controlador (si escribieron un controlador de robo de archivos y lo pusieron en la pila del sistema de archivos) si están muy dedicados a deslizar cada archivo temporal.

Como regla general, cualquier información que deba cifrarse no debe escribirse en un archivo sin cifrar. Los contenidos de los archivos no están bajo su control directo, y los datos sin cifrar deben estar.

El cifrado debería ser posible sobre la marcha con esquemas de cifrado estándar. Puede ser un poco más complicado que hacer una gran llamada de cifrado, pero definitivamente debería ser posible utilizando cualquier biblioteca de cifrado competente.

El administrador puede hacer cualquier cosa . Si el administrador es tu enemigo, entonces has perdido. Él puede copiar tus archivos preciosos sin importar dónde los pongas; Incluso puede leer directamente los contenidos de RAM de su proceso PHP.

Si el administrador es tu amigo, tus próximos enemigos son otras personas que tienen algún tipo de acceso a la misma máquina, por ejemplo. usuarios normales (no administradores) de la máquina y / u otros scripts PHP que se ejecutan en el mismo servidor. El tmpfile de PHP se basa (al menos en sistemas similares a Unix) en la función tmpfile() proporcionada por el sistema operativo (en realidad, una función libc). Si usa Linux, tiene suerte: esa implementación específica crea el archivo con un nombre aleatorio en /tmp y lo elimina inmediatamente . Según la semántica de Unix, el archivo todavía existe (toma algo de espacio en el sistema de archivos) pero el nombre se destruye, prohibiendo el acceso de otros usuarios.

Es posible que aún tenga que temer a otros scripts PHP, si son hostiles y el motor PHP no está correctamente restringido, porque estos scripts se ejecutan con la misma cuenta que la suya (la cuenta a nivel del sistema operativo, es decir, el usuario de Unix que se ejecuta el servidor web) y, por lo tanto, puede acceder al archivo desde un enlace en /proc . Pero eso es bastante extremo; Si personas distintas, potencialmente hostiles entre sí, pueden agregar sus propios scripts PHP al mismo servidor sin aislamiento entre ellos, entonces hay algo muy incorrecto en la estructura del servidor y el administrador no está haciendo su trabajo.

1. Como un archivo temporal es lo mismo que un archivo normal (en el mismo sentido en que se escribe en el disco, aunque solo sea por un período corto), aún podría recuperarse utilizando una herramienta de recuperación de datos hasta que se sobrescriba. Por lo que sé, cuando se elimina el archivo temporal, está "desvinculado", y no se borra de forma segura
2. La carpeta temporal se establece en un nivel de sistema operativo, por lo que, en teoría, podrían cambiar la ubicación, pero debería seguir eliminándose al final de la ejecución de los scripts independientemente de la carpeta
3. Dado que el archivo existe durante toda la duración del script (o hasta que se cierre explícitamente), es posible que puedan ver el directorio y copiar cualquier cosa que aparezca en él. El archivo debe tener el propietario configurado para quien lo cree, pero como el administrador tendrá una raíz, tendrá acceso de todos modos.

Para abordar el punto 1, puede llamar srm y eliminarlo explícitamente, lo que Debe evitar que se recupere. En cuanto al punto 2 y 3, está fuera de su alcance a menos que usted mismo pueda asegurar el servidor.

Espero que esto ayude