subir - Detener a las personas que cargan archivos PHP maliciosos a través de formularios
subir pdf php (10)
Tengo un formulario de carga creado en php en mi sitio web donde las personas pueden cargar un archivo zip. El archivo comprimido se extrae y todas las ubicaciones de archivos se agregan a una base de datos. El formulario de carga es para que las personas carguen imágenes, obviamente, con los archivos dentro de la carpeta zip. No puedo verificar qué archivos se están cargando hasta que se haya extraído el archivo. Necesito un fragmento de código que elimine todos los archivos que no sean formatos de imagen (.png, .jpeg, etc.). Estoy realmente preocupado porque las personas puedan subir archivos php maliciosos, ¡un gran riesgo de seguridad! También necesito estar al tanto de las personas que cambian las extensiones de los archivos php tratando de evitar esta característica de seguridad.
Este es el script original que utilicé http://net.tutsplus.com/videos/screencasts/how-to-open-zip-files-with-php/
Este es el código que realmente extrae el archivo .zip:
function openZip($file_to_open) {
global $target;
$zip = new ZipArchive();
$x = $zip->open($file_to_open);
if($x === true) {
$zip->extractTo($target);
$zip->close();
unlink($file_to_open);
} else {
die("There was a problem. Please try again!");
}
}
Gracias, Ben.
Realmente me preocupa que las personas puedan subir archivos php maliciosos, ¡un gran riesgo de seguridad!
¡La punta del iceberg!
También necesito estar al tanto de las personas que cambian las extensiones de los archivos php tratando de evitar esta característica de seguridad.
Generalmente, el cambio de las extensiones impedirá que PHP interprete esos archivos como scripts. Pero ese no es el único problema. Hay más cosas que ''... php'' que pueden dañar el servidor; ''.htaccess'' y los archivos con el bit X establecido son los más obvios, pero de ningún modo hay que preocuparse por nada. Incluso ignorando las cosas del lado del servidor, hay un gran problema en el lado del cliente.
Por ejemplo, si alguien puede cargar un archivo ''.html'', puede incluir una etiqueta <script> que secuestra la sesión de un usuario externo y borra todos sus archivos cargados o cambia su contraseña o algo así. Este es un ataque clásico de cross-site-scripting (XSS).
Además, gracias a los comportamientos de "detección de contenido" de algunos navegadores (principalmente IE), un archivo que se carga como ''.gif'' en realidad puede contener HTML malicioso como este. Si IE ve indicadores como (pero no limitados a) ''<html>'' cerca del inicio del archivo, puede ignorar el ''Tipo de contenido'' servido y mostrarse como HTML, lo que da como resultado XSS.
Además, es posible crear un archivo que sea una imagen válida que aceptará el analizador de imágenes y que contendrá HTML incorporado. Existen varios resultados posibles según la versión exacta del navegador del usuario y el formato exacto del archivo de imagen (los archivos JPEG, en particular, tienen un conjunto muy variable de posibles formatos de encabezado). Hay mitigations en IE8, pero eso no sirve de nada por ahora, y debes preguntarte por qué no pueden simplemente dejar de hacer sniffing de contenido, idiotas MS en lugar de cargarnos con extensiones shonky no estándar para encabezados HTTP que deberían tener Solo trabajé en primer lugar.
Estoy cayendo en una diatriba de nuevo. Me detendré. Tácticas para servir de forma segura las imágenes proporcionadas por el usuario:
1: Nunca almacene un archivo en el sistema de archivos de su servidor usando un nombre de archivo tomado de la entrada del usuario. Esto evita errores y ataques: los diferentes sistemas de archivos tienen reglas diferentes sobre qué caracteres son permitidos en un nombre de archivo, y es mucho más difícil de lo que se piensa para ''desinfectar'' los nombres de archivo.
Incluso si tomas algo muy restrictivo como "solo letras ASCII", todavía tienes que preocuparte por los nombres demasiado largos, demasiado cortos y reservados: intenta guardar un archivo con un nombre tan inocuo como "com.txt" en un Servidor Windows y mire cómo cae su aplicación. ¿Crees que sabes todas las rarezas extrañas de los nombres de ruta de todos los sistemas de archivos en los que se ejecuta tu aplicación? ¿Confidente?
En su lugar, almacene los detalles del archivo (como nombre y tipo de medio) en la base de datos, y use la clave principal como nombre en su almacén de archivos (por ejemplo, "74293.dat"). Luego necesita una forma de atenderlos con diferentes nombres de archivo aparentes, como un script de descarga escupiendo el archivo, un script de descarga que hace un redireccionamiento interno del servidor web o reescritura de URL.
2: tenga mucho cuidado con ZipArchive. Se han producido vulnerabilities transversales en extractTo del mismo tipo que han afectado a la mayoría de los extractores ZIP basados en rutas. Además, te expones al ataque de las bombas ZIP . Lo mejor es evitar cualquier peligro de nombres de archivo incorrectos, recorriendo cada entrada de archivo en el archivo (por ejemplo, usando zip_read/zip_entry_* ) y verificando sus detalles antes de desempaquetar manualmente su flujo a un archivo con nombre conocido y buenas banderas de modo, que usted generado sin la ayuda del archivo. Ignora las rutas de carpeta dentro del ZIP.
3: si puede cargar un archivo de imagen y guardarlo de nuevo , especialmente si lo procesa de alguna manera intermedia (por ejemplo, para cambiar el tamaño / miniatura, o agregar una marca de agua), puede estar razonablemente seguro de que los resultados serán limpiar. Teóricamente, podría ser posible hacer una imagen que apuntara a un compresor de imagen particular, de modo que cuando se comprimiera, los resultados también se verían como HTML, pero eso me parece un ataque muy difícil.
4: Si puede salirse con la suya publicando todas sus imágenes (es decir, usando ''Content-Disposition: attachment'' en un script de descarga), probablemente esté seguro. Pero eso podría ser una gran molestia para los usuarios. Sin embargo, esto puede funcionar en conjunto con (3), al ofrecer imágenes más pequeñas y procesadas en línea y tener las imágenes originales de mayor calidad disponibles solo como descarga.
5: si debe publicar imágenes sin modificar en línea, puede eliminar el riesgo de creación de scripts entre sitios al servirlos desde un dominio diferente. Por ejemplo, use ''images.example.com'' para imágenes que no sean de confianza y ''www.example.com'' para el sitio principal que contiene toda la lógica. Asegúrese de que las cookies estén limitadas solo al host virtual correcto y de que los hosts virtuales estén configurados para que no puedan responder más que con sus nombres propios (consulte también: ataques de reenlace DNS). Esto es lo que hacen muchos servicios de correo web.
En resumen, el contenido de los medios enviados por el usuario es un problema.
En resumen del resumen, AAAARRRRRRRGGGGHHH.
ETA vuelve a comentar:
en la parte superior que mencionaste sobre "archivos con el bit X establecido", ¿qué quieres decir con eso?
No puedo hablar de ZipArchive.extractTo() ya que no lo he probado, pero muchos extractores, cuando se les pide que vuelquen archivos de un archivo, recrearán [algunos de] los indicadores de modo de archivo Unix asociados con cada archivo (si el archivo fue creado en un Unix y realmente tiene banderas de modo). Esto puede causarle problemas de permisos si, por ejemplo, falta el permiso de lectura del propietario. Pero también puede ser un problema de seguridad si su servidor está habilitado para CGI: un bit X puede permitir que el archivo se interprete como un script y se pase a cualquier intérprete de guiones incluido en el hashbang de la primera línea.
pensé que .htaccess tenía que estar en el directorio raíz principal, ¿no es así?
Depende de cómo se configura Apache, en particular, la directiva AllowOverride. Es común que los hosts de uso general permitan AllowOverride en cualquier directorio.
¿Qué pasaría si alguien todavía cargara un archivo como ../var/www/wr_dir/evil.php?
Esperaría que el ''...'' líder se descartara, eso es lo que otras herramientas que han sufrido la misma vulnerabilidad han hecho.
Pero todavía no confío en extractTo() contra la entrada hostil, hay demasiadas cosas raras en el nombre del archivo / árbol de directorios que pueden salir mal, especialmente si esperas que alguna vez se ejecute en los servidores de Windows. zip_read() le da un control mucho mayor sobre el proceso de desarchivación, y por lo tanto, el atacante mucho menos.
Ahora confía en el espacio de su disco duro para extraer. Puede verificar fileheaders para determinar qué tipo de archivos son. probablemente haya bibliotecas para eso.
offtopic: no es mejor dejar que el usuario seleccione un par de imágenes en lugar de cargar un archivo zip. Mejor para las personas que no saben qué zip es (sí existen)
Beaware de este paso PHP malicioso a través de getimagesize ()
Inyectar PHP a través de funciones de imagen que intentan asegurar que las imágenes estén seguras usando la función getimagesize ()
lea más aquí ha.ckers.org/blog/20070604/…
Mejor para su logotipo de usuario use gravatar como aquí utilizado por ;)
Es posible que también desee considerar la posibilidad de realizar una detección de tipo MIME con la siguiente biblioteca:
No veo el riesgo de tener renombrados archivos php en su base de datos ... Siempre y cuando no los evalúe como archivos PHP (o para nada), no pueden hacer demasiado daño, y como no hay extensión .php, el motor php no los tocará.
Supongo que también puedes buscar los archivos para <?php ...
Además : asuma lo peor de los archivos cargados en su máquina. Se cambió el nombre de la carpeta en la que se guardan los "virus" y se trata en consecuencia. No lo haga público, no otorgue ningún permiso de inicio de archivo (especialmente el usuario de php), etc.
Personalmente, agregaría algo a la configuración de Apache para asegurarme de que sirve archivos PHP como texto desde la ubicación en la que se cargan los archivos, para que esté a salvo y pueda permitir que otros tipos de archivos se carguen en el futuro.
Primero, debe prohibir todos los archivos que no tengan una extensión de archivo de imagen adecuada. Y después de eso, puede usar la función getimagesize para verificar si los archivos son archivos de imágenes regulares.
Pero, además, debe tener en cuenta que algunos formatos de imagen permiten comentarios y otra metainformación. Esto podría usarse para código malicioso como JavaScript que algunos navegadores ejecutarán bajo ciertas circunstancias (ver Risky MIME sniffing en Internet Explorer ).
Probablemente no deberías confiar solo en la extensión del nombre de archivo, entonces. Intente pasar cada archivo a través de una biblioteca de imágenes para validar que realmente es una imagen, también.
Si configura php para que solo analice los archivos que terminan en .php, puede cambiar el nombre de un archivo de somename.php a somename.php.jpeg y estará a salvo.
Si realmente desea eliminar los archivos, hay una biblioteca zip disponible para php. Puede usarlo para verificar los nombres y extensiones de todos los archivos dentro del archivo comprimido cargado, y si contiene un archivo php, proporcione al usuario un mensaje de error.
Usa la función getimagesize. Procedimiento completo: - 1.) Extraiga la extensión de la imagen / archivo cargado y luego compare la extensión con la extensión permitida. 2.) Ahora crea una cadena aleatoria para cambiar el nombre del archivo cargado. La mejor idea es md5(session_id().microtime()) . No se puede duplicar y si su servidor es muy rápido y puede procesar menos de un microsegundo que usar una variable incrementada y agregarlos con una cadena. ahora mueva ese archivo.
Un consejo Deshabilite el procesamiento de archivos PHP en el directorio de carga, siempre evitará cualquier ataque al servidor y, si es posible, agregue su htaccess en el directorio raíz o en el archivo de configuración httpd y deshabilite los archivos htaccess desde allí ahora resuelve sus problemas máximos.