Validación del lado del cliente

El código de validación que ha proporcionado está en JavaScript. Eso sugiere que es el código que usa para hacer la validación en el cliente.

La regla número uno de asegurar webapps es nunca confiar en el cliente . El cliente está bajo el control total del usuario, o en este caso, el atacante. No puede estar seguro de que cualquier código que envíe al cliente se use para nada, y que ningún bloque que ponga en el cliente tenga ningún valor de seguridad. La validación en el cliente es solo para proporcionar una experiencia de usuario fluida, no para imponer realmente ninguna restricción relevante para la seguridad.

Un atacante podría simplemente cambiar esa pieza de JavaScript en su navegador, o desactivar los scripts completamente, o simplemente no enviar el archivo desde un navegador, sino crear su propia solicitud POST con una herramienta como curl.

Debe revalidar todo en el servidor. Eso significa que su PHP debe verificar que los archivos sean del tipo correcto, algo que su código actual no hace.

La forma de hacerlo es un problema general que creo que está fuera del alcance de su pregunta, pero esta pregunta son buenos lugares para comenzar a leer. Es posible que desee echar un vistazo a su .htaccess de archivos también.

Obteniendo la extensión

Tal vez no sea un problema de seguridad, pero esto es una mejor manera de hacerlo:

$ext = pathinfo($filename, PATHINFO_EXTENSION);

Funciones de PHP mágicas

  

Cuando almaceno datos de cuadros de edición, utilizo las tres funciones de PHP para limpiarlos:

$cleanedName = strip_tags($_POST[name]); // Remove HTML tags
$cleanedName = htmlspecialchars($cleanedName); // Allow special chars, but store them safely. 
$cleanedName = mysqli_real_escape_string($connectionName, $cleanedName);

Esta no es una buena estrategia. El hecho de que mencione esto en el contexto de la validación de las extensiones de archivo hace que me preocupe que esté lanzando un par de funciones relacionadas con la seguridad en su entrada con la esperanza de que resuelva el problema.

Por ejemplo, debería usar declaraciones preparadas y no escapar para protegerse contra SQLi. El escape de etiquetas HTML y caracteres especiales para evitar XSS debe realizarse después de que los datos se recuperan de la base de datos, y cómo hacerlo depende de dónde inserte esos datos. Y así sucesivamente, y así sucesivamente.

Conclusión

No estoy diciendo que esto sea malo, pero parece que estás cometiendo muchos errores aquí. No me sorprendería si hubiera otras vulnerabilidades. Si su aplicación maneja información confidencial, le recomendaría encarecidamente que deje que alguien con experiencia en seguridad la examine antes de ponerla en producción.

En primer lugar, si alguien explotó una función de carga de archivos, asegúrese de que está verificando el archivo en el cliente y servidor . Omitir la protección de JavaScript del lado del cliente es trivial.

Segundo, asegúrese de revisar e implementar estas ideas de OWASP .

Eso debería cubrir la mayoría de tus problemas. Además, asegúrese de que no tiene ningún otro defecto no parcheado en su servidor (por ejemplo, complementos desactualizados, servidores explotables, etc.)

Es súper importante tener en cuenta que PHP fue diseñado para integrarse en otro contenido . Específicamente, se diseñó para integrarse en páginas HTML, complementando una página en gran parte estática con fragmentos menores de datos actualizados dinámicamente.

Y, sencillamente, no le importa en qué está incrustado . El intérprete de PHP escaneará cualquier tipo de archivo arbitrario y ejecutará cualquier contenido de PHP que esté debidamente marcado con etiquetas de script.

El problema histórico que esto ha causado es que, sí, las cargas de imágenes pueden contener PHP. Y si el servidor web está dispuesto a filtrar esos archivos a través del intérprete de PHP, ese código se ejecutará. Ver el fiasco del plugin "Tim Thumb" de Wordpress.

La solución adecuada es asegurarse de que su servidor web nunca, nunca, trate el contenido no confiable como algo que debería ejecutar a través de PHP. Intentar filtrar la entrada es una forma de hacerlo, pero como ha encontrado, limitado y propenso a errores.

Es mucho mejor verificar que tanto la ubicación del archivo como la extensión del archivo se utilicen para definir qué procesará PHP y para segregar las cargas y otros contenidos no confiables en ubicaciones y extensiones que no se procesarán. (La forma en que lo hace varía de un servidor a otro y se ve afectada por el hecho de que "hacer que las cosas funcionen normalmente significa aflojar la seguridad de una forma que no conoce".)

Puedes deshabilitar PHP en tu directorio de carga mediante .htaccess para que tu servidor no ejecute ningún código PHP en el directorio y en sus subdirectorios.

Cree un archivo .htaccess dentro de su directorio de carga con esta regla:

php_flag engine off

Tenga en cuenta que la regla .htaccess solo funcionará si su servidor PHP se está ejecutando en modo mod_php .

Editar: Por supuesto, olvidé mencionar que .htaccess solo funciona en Apache.

Solo está verificando la extensión, esto no necesariamente se correlaciona con el tipo de archivo real. En el lado del servidor, puede usar algo como exif_imagetype para verificar que el archivo es una imagen. uso de tipo de imagen exif: enlace

Estoy totalmente de acuerdo con la respuesta aceptada, pero sugeriría hacer un poco más que simplemente jugar con el nombre del archivo. Debe volver a comprimir el archivo original / cargado con PHP usando GD o Imagick y usar la nueva imagen . De esta manera, destruye cualquier código inyectado (para ser honesto, el 90% del tiempo, hay formas de hacer que el código sobreviva a la compresión, pero es mucho trabajo).

También, podría usar archivos .htaccess para evitar que el directorio de carga ejecute el código PHP (no sé sobre IIS y probablemente haya un .webconfig equivalente).

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

De esta manera, el archivo cargado se ejecutará solo si la "extensión final" es PHP, por lo que no se ejecutará image.php.jpg.

Algunos recursos:

• Un buen artículo sobre las cargas de archivos
• manual de PHP que instala Apache

Una posible parte de una solución aquí es mantener la imagen, pero también hacer una copia redimensionada con PHP de modo que pueda asegurarse de que está obteniendo una imagen y reducir el tamaño de la imagen original. Esto tiene varios efectos positivos:

• Nunca permite que la imagen original se use para la visualización, por lo que es más segura
• Ahorra espacio en su servidor (lo que puede o no ser un problema)
• Mejor tiempo de carga para los visitantes del sitio, ya que no estarían esperando la carga de una imagen de 10 MB. En su lugar, tienen una imagen de 300 KB en un tamaño razonable cargando

El punto principal es que nunca se puede confiar en los datos de usuario. Valide todo, carga de archivos, entradas, cookies para asegurarse de que los datos no puedan causar problemas.

Solo tengo una pequeña cosa que agregar a esto que no se ha tocado: usar una estrategia de lista blanca.

Como otros ya lo han señalado, confiar en la validación del lado del cliente ciertamente no es algo bueno. También ha empleado una estrategia de lista negra, lo que significa que está revisando las cosas que sabe / piensa que son malas y está permitiendo todo lo demás. Una estrategia mucho más sólida es verificar si las cosas que usted sabe están bien y rechazar todo lo demás.

En ocasiones, esto es una compensación contra los comentarios de los usuarios, como permitir que los usuarios sin experiencia sepan lo que deben hacer para subir una imagen con éxito.

En mi experiencia, las dos estrategias no son necesariamente mutuamente excluyentes siempre que se usen para diferentes propósitos: validación de lista negra del lado del cliente para comentarios de los usuarios y validación de lista blanca del lado del servidor para la seguridad.

Permito la carga de imágenes, pero asumo que cada una está cargada con código troyano. Coloco temporalmente la imagen cargada sobre la raíz web al cargarla, luego uso ImageMagick para convertirla a BMP, luego a JPG, luego la muevo a donde la aplicación web puede usarla. Esto elimina efectivamente cualquier código PHP incrustado.

Como @Sneftel señala en el comentario a continuación, realizar esta conversión en un JPG dará como resultado una degradación de la imagen. Para mi propósito, esta es una compensación aceptable.

Verifique las etiquetas EXIF de una imagen o use una función strpos para encontrar un código PHP en el contenido de la imagen. Ejemplo:

$imageFile = file_get_contents($your_image_temp_path); // ATTENTION! Temporary path for images is really needed for security reasons!
$dangerousSyntax = ['<?', '<?php', '?>'];
$error = '';
foreach($dangerousSyntax as $value) {
  $find = strpos($value, $imageFile);
  if( $find !== true ) {
    unlink($your_image_temp_path);
    $error = 'We found a dangerous code in your image';
  }
}

if(!empty($error)) { 
  die($error);
}

Además de la respuesta aceptada, sugeriría usar la función getImageSize incorporada en PHP para obtenga el tipo MIME y asegúrese de que un archivo PHP no se oculte bajo una extensión de archivo de imagen.