Cómo sanitizar uploads de usuario en el sitio y panel de tu servidor de MU Online

El sitio y el panel de un servidor de MU Online casi siempre aceptan algún tipo de upload de usuario — avatar de perfil, adjunto de ticket de soporte, imagen de post en el foro de la comunidad. Cada uno de esos puntos de entrada es, sin el tratamiento correcto, una puerta abierta para la subida de webshells, el defacement del sitio o el compromiso total del servidor web. Este tutorial cubre la sanitización de uploads de forma completa: validación de tipo real, límites de tamaño, renombrado seguro, almacenamiento fuera del webroot y reprocesamiento de imágenes, con ejemplos prácticos en PHP, el lenguaje más común en paneles de servidores de MU.

Por qué el upload de archivos es uno de los vectores de ataque más comunes

Los paneles de servidores de MU Online se construyen frecuentemente de forma rápida, con foco en la funcionalidad (ranking, tienda, votación) y poca atención a la seguridad de upload. Un campo de "subir avatar" o "adjuntar captura en el ticket" mal validado permite que un atacante envíe un archivo .php disfrazado de imagen y, si ese archivo cae en una carpeta pública con permiso de ejecución, obtiene ejecución de código directamente en el servidor — el peor escenario posible, peor incluso que una inyección SQL aislada, porque otorga control total de la máquina.

El error fundamental: confiar en la extensión del archivo

La validación más común y más fallida en los paneles es verificar solo la extensión del nombre del archivo enviado. Un atacante puede nombrar el archivo shell.php.jpg, manipular el campo MIME type enviado por el navegador (que es controlado por el cliente, por lo tanto no confiable), o usar técnicas de doble unicode para burlar filtros ingenuos. La extensión del nombre del archivo es metadato, no prueba del contenido real.

Validando el tipo real del archivo por su contenido (magic bytes)

La validación confiable verifica los primeros bytes del archivo (firma binaria), no el nombre ni el encabezado MIME enviado por el cliente. En PHP, la función finfo_file (extensión Fileinfo) lee el contenido real del archivo:

<?php
function validarTipoReal(string $rutaTemp, array $tiposPermitidos): bool {
    $finfo = finfo_open(FILEINFO_MIME_TYPE);
    $mimeReal = finfo_file($finfo, $rutaTemp);
    finfo_close($finfo);

    return in_array($mimeReal, $tiposPermitidos, true);
}

$tiposPermitidos = ['image/jpeg', 'image/png', 'image/webp'];
if (!validarTipoReal($_FILES['avatar']['tmp_name'], $tiposPermitidos)) {
    http_response_code(400);
    exit('Tipo de archivo no permitido.');
}

Esta verificación debe ser la primera barrera, antes de cualquier otra validación, porque impide que un archivo con payload disfrazado de imagen llegue a las etapas siguientes del procesamiento.

Limitando el tamaño del archivo

Además del límite configurado en PHP (upload_max_filesize, post_max_size), valida el tamaño explícitamente en el código de la aplicación, porque los límites de servidor mal configurados o ausentes en entornos de desarrollo no protegen a producción por sí solos.

<?php
$limiteBytes = 1 * 1024 * 1024; // 1MB para avatar
if ($_FILES['avatar']['size'] > $limiteBytes) {
    http_response_code(400);
    exit('El archivo excede el tamaño máximo permitido.');
}

Renombrando el archivo en el momento del guardado

Nunca conserves el nombre original enviado por el usuario. Nombres como ../../../var/www/config.php (path traversal) o nombres duplicados entre usuarios distintos son riesgos reales. Genera un identificador nuevo, generalmente un hash o UUID, y asocia la extensión validada (no la extensión original del envío):

<?php
$extensionSegura = match ($mimeReal) {
    'image/jpeg' => 'jpg',
    'image/png' => 'png',
    'image/webp' => 'webp',
    default => throw new RuntimeException('Tipo no soportado.'),
};

$nombreFinal = bin2hex(random_bytes(16)) . '.' . $extensionSegura;

Almacenando los uploads fuera del webroot

Incluso con validación rigurosa, la defensa en profundidad recomienda guardar los archivos enviados fuera de la carpeta pública del servidor web (webroot), o en una carpeta configurada explícitamente sin permiso de ejecución de scripts. Si un archivo malicioso escapa a todas las validaciones, aun así no podrá ejecutarse directamente por URL.

Estructura recomendada:
/var/www/muweb/           <- webroot pública (Apache/Nginx apunta aquí)
/var/data/uploads/         <- fuera del webroot, los uploads reales quedan aquí
/var/www/muweb/serve.php   <- script que lee de /var/data/uploads/ y entrega la imagen

El serve.php (o ruta equivalente) lee el archivo del directorio protegido y lo entrega al navegador con el Content-Type correcto, sin exponer nunca la ruta real de almacenamiento ni permitir que el archivo sea accedido como script.

Configurando el servidor web para negar la ejecución en la carpeta de upload

Como capa adicional, incluso si los uploads quedan dentro del webroot por alguna limitación de infraestructura, desactiva la ejecución de scripts en esa carpeta específicamente. En Apache, vía .htaccess en la carpeta de uploads:

<FilesMatch "\.(php|php5|phtml|pl|py|cgi|sh)$">
    Require all denied
</FilesMatch>

En Nginx, el equivalente es garantizar que el bloque de location de la carpeta de uploads no pase archivos al procesador PHP-FPM, sirviéndolos solo como estáticos.

Reprocesando imágenes para eliminar payloads escondidos

Una técnica conocida de ataque usa "imágenes polimórficas" — archivos que son simultáneamente un .jpg válido y un script válido, dependiendo de cómo se interpreten. Reabrir la imagen con una biblioteca de procesamiento y guardarla de nuevo (aunque no se altere la calidad visual) reconstruye el archivo desde cero, eliminando cualquier payload incrustado fuera de la estructura estándar de la imagen:

<?php
function reprocesarImagen(string $origen, string $destino, string $mime): void {
    $imagen = match ($mime) {
        'image/jpeg' => imagecreatefromjpeg($origen),
        'image/png' => imagecreatefrompng($origen),
        'image/webp' => imagecreatefromwebp($origen),
    };

    match ($mime) {
        'image/jpeg' => imagejpeg($imagen, $destino, 85),
        'image/png' => imagepng($imagen, $destino),
        'image/webp' => imagewebp($imagen, $destino, 85),
    };

    imagedestroy($imagen);
}

Aplicando las mismas reglas a adjuntos que no son imágenes

Los adjuntos de ticket de soporte a veces necesitan aceptar otros formatos (PDF, texto de log). Para esos casos, la validación de magic bytes sigue siendo válida, pero la defensa en profundidad gana aún más importancia — nunca sirvas un PDF o archivo de texto enviado por un usuario desde una carpeta con permiso de ejecución, y considera agregar el encabezado Content-Disposition: attachment al servir esos archivos, forzando la descarga en vez de la renderización inline en el navegador.

Registrando y limitando la tasa de uploads

Además de la validación de contenido, limita cuántos uploads puede hacer una cuenta en un intervalo de tiempo (ej.: 10 uploads por hora) para mitigar el abuso de almacenamiento y los intentos automatizados de bypass por fuerza bruta de variaciones de payload. Registrar metadatos de cada upload (cuenta, IP, hash del archivo, resultado de la validación) también ayuda a identificar cuentas comprometidas o comportamiento de bot rápidamente.

Errores comunes y soluciones

Lista de verificación de sanitización de uploads

• Validación de tipo real por magic bytes implementada (no solo extensión/MIME del cliente).
• Límite de tamaño definido por tipo de upload (avatar, ticket, foro).
• Archivos renombrados con hash/UUID en el momento del guardado.
• Uploads almacenados fuera del webroot o en carpeta sin permiso de ejecución.
• Servidor web configurado para negar la ejecución de scripts en la carpeta de uploads.
• Imágenes reprocesadas (GD/Imagick) antes del almacenamiento final.
• Rate limiting y log de uploads por cuenta/IP implementados.

Con los uploads sanitizados, revisa también los demás puntos de entrada de datos de tu panel — el tutorial de creación de servidor de MU Online cubre la base de infraestructura sobre la cual deben aplicarse estas protecciones.

Preguntas frecuentes