Hacer una lista negra de tipos de archivo para proteger la aplicación PHP

Question

Hacer una lista negra de tipos de archivo para proteger la aplicación PHP

#1 de Steffen Ullrich (22 votos)
#2 de meowmaster (14 votos)
#3 de tim (6 votos)
#4 de D0c0z (2 votos)

9

Estoy trabajando en un sistema PHP donde el usuario puede cargar archivos.

Estoy tratando de proteger el sistema de códigos maliciosos, por lo que estoy pensando en algún tipo de lista negra de archivos que debo bloquear de la carga.

Sé que una lista blanca es mejor que una lista negra y este es mi enfoque común, pero en este caso Necesito hacer una lista negra de archivos por muchas razones (fuera de mi control), pero sigo buscando seguridad (si es posible).

Este es mi script actual (estoy revisando el tipo MIME para obtener el tipo de archivo):

        $finfo = finfo_open(FILEINFO_MIME_TYPE);
        $check= finfo_file($finfo,$file["tmp_name"]);
        finfo_close($finfo);

        $dangerMime = array('application/x-bsh', 'application/x-sh', 'application/x-shar', 'text/x-script.sh');
        if (in_array($check, $dangerMime)) {
            //block upload
        }
        else {
            //allow upload
        }

La lista actual de tipos MIME a bloquear es:

'application / x-bsh', 'application / x-sh', 'application / x-shar', 'text / x-script.sh'

Estoy intentando bloquear cualquier archivo .sh , ya que el sistema se está ejecutando en un CentOS bajo Apache. ¿Hay algún otro tipo de archivo que también deba bloquear?

A continuación hay información importante:

El servidor es un CentOS 7.2 con Apache 2.4.6. Los siguientes son los permisos del directorio de subidas:

drwxr-xr-x  4 apache apache 4096 Jan  8 12:23 uploads

Nota: En este proyecto, estoy actuando como desarrollador, por lo que no puedo cambiar los permisos de archivo.

php file-upload file-types blacklist

pregunta James 31.01.2016 - 19:55

fuente

4 respuestas

14

No bloquee ningún tipo específico de MIME. Bloquea cualquier tipo de ejecución de los archivos subidos. Una forma sencilla es almacenar los archivos cargados fuera de la raíz web y servirlos mediante scripts. Si eso no es posible, almacene los archivos en un subdirectorio y configure su servidor no ejecutar ningún script en ese directorio . Recuerde hacer esto para cualquier lenguaje de scripts que posiblemente esté habilitado en el servidor.

Si no puede modificar la configuración por varios motivos, verifique el nombre del archivo y hágalo correctamente. Las cadenas PHP pueden contener bytes NULOS, los nombres de archivos no pueden, por lo que si un atacante carga un archivo llamado "hack.php \ 0.jpg", puede ver la extensión como ".jpg", que es válida, pero se guardará como "hack .php ", haciéndote vulnerable de nuevo. Verifique los caracteres en un nombre de archivo con una lista blanca.

respondido por el meowmaster 01.02.2016 - 04:17

fuente

6

¿Hay algún otro tipo de archivo que también deba bloquear?

No importa, ya que finfo_file se puede omitir , vea por ejemplo aquí: Codificación de shells web en trozos PNG IDAT . mime_content_type tampoco parece ser más confiable.

Debe verificar la extensión del archivo además de la verificación de tipos MIME, ya que es mucho más confiable, ya que los nombres de los archivos son mucho menos complejos que el contenido de los archivos.

Una verificación adicional de tipo mime sigue siendo una buena idea como defensa en profundidad, para filtrar ataques simples. Como usted dijo, una lista blanca sería el enfoque correcto , pero si definitivamente necesita ir con una lista negra, al menos agregaría tipos de métrica de PHP a la lista de bloqueo:

text / php
texto / x-php
application / php
aplicación / x-php
application / x-httpd-php
application / x-httpd-php-source

Además, ¿realmente necesita ejecución en el directorio de subidas? Si no, elimínelo para mayor seguridad.

respondido por el tim 31.01.2016 - 20:13

fuente

2

Sugiero una cuarentena a corto plazo de todos los archivos cargados. Puede utilizar los sistemas locales de exploración y herramientas de AV en una cárcel temporal. De esta manera, podría agregar una rutina para buscar archivos maliciosos e ignorar los diferentes nombres de los archivos. Esto detiene el juego whack-a-mole.

Esto agregaría algo de latencia a la aplicación.

Sé que esto no es una solución de codificación, pero aborda los defectos fundamentales de la lista negra y no le obliga a ajustar los permisos, ya que dijo que no tiene control.

Me he encontrado con una aplicación que hizo una lista negra de la forma que propones. Lo encontré cuando estábamos haciendo el análisis forense después de que el adversario había tomado el control y se había estado alimentando de los activos corporativos durante nueve meses. Si esta no es una razón suficiente para detener la inclusión en listas negras, diviértase. whack-whack.

respondido por el D0c0z 02.02.2016 - 17:33

fuente

Lea otras preguntas en las etiquetas php file-upload file-types blacklist

BCrypt del lado del cliente, almacene sal y hash por separado en la base de datos MySQL [duplicado] Varios campos de contraseña para un inicio de sesión [duplicado]

score 22 · Accepted Answer

De su descripción no queda claro por qué quiere bloquear estos archivos exactamente. Veo las siguientes posibilidades:

Desea bloquear archivos que puedan infectar el propio servidor. Desafortunadamente, esto puede ser sobre cualquier cosa: shell, perl, python, awk, ... y por supuesto, binarios compilados. Pero para que estos archivos se ejecuten sin llamarlos explícitamente con un intérprete, se debe establecer el bit ejecutable, lo cual no debería ser el caso si el archivo se carga desde una aplicación web. Este es al menos el caso en los sistemas UNIX, porque en Windows la extensión es suficiente y también tiene PoweShell, JavaScript, Batch y todos los demás archivos. Aún así, algo debe al menos desencadenar la ejecución del archivo o tener el directorio de carga en la ruta de las bibliotecas DLL y compartidas.
O desea bloquear archivos que podrían ser ejecutados por el propio servidor web, es decir, desde dentro de la aplicación web. Estos son archivos PHP, ASP, CGI ... que se ejecutarán a través de una URL y causarán daños al usuario o al servidor. Por supuesto, el único funciona si se puede acceder a su directorio de carga mediante una URL o si el atacante logra salir del directorio de carga con ataques de ruta o similares, o si el atacante administra algún código del lado del servidor para incluir estos archivos (es decir, inclusión de archivos locales). ataque).
O desea bloquear los archivos que podrían incluirse para proporcionar malware al usuario, es decir, documentos PDF corruptos, redireccionamiento de JavaScript a sitios de malware. En este caso, probablemente tenga un directorio de carga al que se puede acceder mediante una URL porque desea que los usuarios descarguen estos archivos. Desafortunadamente para tales archivos, no solo el tipo de archivo que ve es importante, sino también el contexto en el que se llaman (es decir, como imagen, script, css, objeto ...) y no puede controlar este uso.

... pero en este caso necesito hacer una lista negra de archivos por muchas razones,

Como obviamente no sabes qué archivos pueden ser peligrosos para nada, este tipo de lista negra no funcionará, nunca. Siempre habrá tipos de archivo que se pierda o el atacante ocultará su archivo detrás de otro tipo, es decir, construirá un polyglot .