¿Es posible que la extensión de la imagen sea propensa a errores para los navegadores?

Cuando está cargando archivos, debe asegurarse de que la extensión del archivo sea una que usted apruebe, de lo contrario se conoce como un enfoque de lista blanca. No debe cambiar el nombre de cada extensión a .jpeg, esto causará problemas. La mayoría de los HTTPD establecerán el tipo de mime en función de la extensión del archivo, que informa al navegador de cómo descodificar el contenido.

Hay otro problema con las cargas de archivos. Apache "retrocederá" en la segunda extensión de archivo si no tiene un tipo mime para la primera extensión de archivo. Entonces, de forma predeterminada, backdoor.php.fjfl se ejecutará como un archivo .php, Ouch. Recomiendo cambiar el nombre del archivo, como a la clave principal, además de tener una lista blanca de extensiones de archivo.

Incluso si el usuario está cargando una imagen válida, puede causar problemas de seguridad. Por ejemplo, los metadatos de las imágenes podrían contener una etiqueta php, que es útil para convertir una simple Archivo local: vulnerabilidad en la ejecución remota de código .

Como dijo @Rook, no deberías cambiar la extensión ya que causará problemas. También señaló que los metadatos podrían contener datos maliciosos, lo cual es muy cierto. Así que aquí están los pasos que debe seguir, aproximadamente:

1. Comprobar el tamaño del archivo: ¿es lo suficientemente masivo como para romper el servidor web a través de DoS?
2. Verificar extensión: es una extensión conocida que admite, por ejemplo, jpg, png, gif
3. Si la extensión es buena, verifique el encabezado del archivo: aunque dice jpg, podría contener el encabezado GIF / PNG / EXE, etc.
4. Eliminar metadatos del archivo: ni siquiera lo lea, simplemente elimínelo
5. Convierta al formato de su elección si lo desea en un formato determinado

En el caso de que alguna de las comprobaciones anteriores falle, simplemente detiene el proceso, borra el archivo y devuelve un simple mensaje de error que explica que la imagen no es buena.

(1) Nunca use ninguna parte de un nombre de archivo enviado por el usuario en su nombre de archivo almacenado. Desinfectar un nombre de archivo es un trabajo traicionero, no es tan fácil de hacer de manera confiable como se ve en todo, especialmente si su aplicación puede terminar ejecutándose en un servidor Windows o Linux.

Almacénelo como algo así como 2395862.jpeg , con el nombre de archivo derivado de, por ejemplo, la clave principal de la entidad de base de datos relacionada.

Si necesita presentar un nombre "amigable" al navegador final, use una reescritura para poder servirlo como /avatar/2395862/anyname.jpeg mientras que en realidad está almacenado como 2395862.jpeg .

(2) Asegúrese de almacenar los archivos en un directorio separado que no contenga nada más. Este directorio debe ser el único al que el usuario de script web tiene acceso de escritura. Debería tener permisos de bloqueo para que solo se puedan servir archivos estáticos. En Apache, esto debe hacerse desde un .htaccess o httpd.conf de nivel superior y las anulaciones desactivadas para que no sea posible que un archivo .htaccess en este directorio tenga algún efecto.

(3) Es posible que los archivos subidos por el usuario contengan contenido que se enmascara como un tipo diferente. Por ejemplo, en algunos navegadores, la presencia de etiquetas HTML en el archivo puede hacer que traten el archivo como un documento HTML, incluido JavaScript. Los complementos también pueden malinterpretar los archivos que dan lugar a secuencias de comandos entre sitios (consulte el ejemplo del ataque GIFAR).

Por este motivo, debe considerar que cualquier repositorio de archivos cargados por el usuario se vea comprometido por los scripts entre sitios, y mitigue esto al entregar todos los archivos cargados por el usuario desde un dominio diferente. De esa manera, cualquier secuencia de comandos inyectada no podrá cruzar la secuencia de comandos del sitio en su sitio web principal. Asegúrese de que no haya manera de acceder a los recursos cargados por el usuario desde su sitio web principal.

El sitio separado para los recursos de usuario puede ser un dominio completamente diferente, o puede ser un subdominio. Pero si es un subdominio, debe asegurarse de que no haya nada en el dominio principal: por lo tanto, si sirve recursos de usuario de avatars.myforum.com , su foro principal puede estar en www.myforum.com pero no debe estar en myforum.com . De lo contrario, los navegadores compartirán cookies entre ellos.