Como sanitizar uploads de usuário no site e painel do seu servidor de MU Online

O site e o painel de um servidor de MU Online quase sempre aceitam algum tipo de upload de usuário — avatar de perfil, anexo de ticket de suporte, imagem de post no fórum da comunidade. Cada um desses pontos de entrada é, sem o tratamento correto, uma porta aberta para upload de webshell, defacement do site ou comprometimento total do servidor web. Este tutorial cobre a sanitização de uploads de forma completa: validação de tipo real, limites de tamanho, renomeação segura, armazenamento fora da webroot e reprocessamento de imagens, com exemplos práticos em PHP, a linguagem mais comum em painéis de servidores de MU.

Por que upload de arquivo é um dos vetores de ataque mais comuns

Painéis de servidores de MU Online são frequentemente construídos rapidamente, com foco em funcionalidade (ranking, loja, votação) e pouca atenção a segurança de upload. Um campo de "enviar avatar" ou "anexar print no ticket" mal validado permite que um atacante envie um arquivo .php disfarçado de imagem e, se esse arquivo cair em uma pasta pública com permissão de execução, ele ganha execução de código diretamente no servidor — o pior cenário possível, pior até que uma injeção SQL isolada, porque dá controle total da máquina.

O erro fundamental: confiar na extensão do arquivo

A validação mais comum e mais falha em painéis é checar apenas a extensão do nome do arquivo enviado. Um atacante pode nomear o arquivo shell.php.jpg, manipular o campo MIME type enviado pelo navegador (que é controlado pelo cliente, portanto não confiável), ou usar técnicas de duplo unicode para burlar filtros ingênuos. A extensão do nome do arquivo é metadado, não prova do conteúdo real.

Validando o tipo real do arquivo pelo conteúdo (magic bytes)

A validação confiável verifica os primeiros bytes do arquivo (assinatura binária), não o nome nem o cabeçalho MIME enviado pelo cliente. Em PHP, a função finfo_file (extensão Fileinfo) lê o conteúdo real do arquivo:

<?php
function validarTipoReal(string $caminhoTemp, array $tiposPermitidos): bool {
    $finfo = finfo_open(FILEINFO_MIME_TYPE);
    $mimeReal = finfo_file($finfo, $caminhoTemp);
    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 arquivo não permitido.');
}

Essa checagem deve ser a primeira barreira, antes de qualquer outra validação, porque ela impede que um arquivo com payload disfarçado de imagem chegue às etapas seguintes do processamento.

Limitando o tamanho do arquivo

Além do limite configurado no PHP (upload_max_filesize, post_max_size), valide o tamanho explicitamente no código da aplicação, porque limites de servidor mal configurados ou ausentes em ambientes de desenvolvimento não protegem produção sozinhos.

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

Renomeando o arquivo no momento do salvamento

Nunca preserve o nome original enviado pelo usuário. Nomes como ../../../var/www/config.php (path traversal) ou nomes duplicados entre usuários diferentes são riscos reais. Gere um identificador novo, geralmente um hash ou UUID, e associe a extensão validada (não a extensão original do envio):

<?php
$extensaoSegura = match ($mimeReal) {
    'image/jpeg' => 'jpg',
    'image/png' => 'png',
    'image/webp' => 'webp',
    default => throw new RuntimeException('Tipo não suportado.'),
};

$nomeFinal = bin2hex(random_bytes(16)) . '.' . $extensaoSegura;

Armazenando uploads fora da webroot

Mesmo com validação rigorosa, a defesa em profundidade recomenda salvar os arquivos enviados fora da pasta pública do servidor web (webroot), ou em uma pasta configurada explicitamente sem permissão de execução de scripts. Se um arquivo malicioso escapar de todas as validações, ele ainda não conseguirá ser executado diretamente por URL.

Estrutura recomendada:
/var/www/muweb/           <- webroot pública (Apache/Nginx aponta aqui)
/var/data/uploads/         <- fora da webroot, uploads reais ficam aqui
/var/www/muweb/serve.php   <- script que lê de /var/data/uploads/ e entrega a imagem

O serve.php (ou rota equivalente) lê o arquivo do diretório protegido e o entrega ao navegador com o Content-Type correto, sem nunca expor o caminho real de armazenamento nem permitir que o arquivo seja acessado como script.

Configurando o servidor web para negar execução na pasta de upload

Como camada adicional, mesmo que uploads fiquem dentro da webroot por alguma limitação de infraestrutura, desative a execução de scripts nessa pasta especificamente. Em Apache, via .htaccess na pasta de uploads:

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

Em Nginx, o equivalente é garantir que o bloco de location da pasta de uploads não repasse arquivos para o processador PHP-FPM, servindo-os apenas como estáticos.

Reprocessando imagens para remover payloads escondidos

Uma técnica conhecida de ataque usa "imagens polimórficas" — arquivos que são simultaneamente um .jpg válido e um script válido, dependendo de como são interpretados. Reabrir a imagem com uma biblioteca de processamento e salvá-la novamente (mesmo sem alterar a qualidade visual) reconstrói o arquivo do zero, eliminando qualquer payload embutido fora da estrutura padrão da imagem:

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

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

    imagedestroy($imagem);
}

Aplicando as mesmas regras a anexos que não são imagem

Anexos de ticket de suporte às vezes precisam aceitar outros formatos (PDF, texto de log). Para esses casos, a validação de magic bytes continua válida, mas a defesa em profundidade ganha ainda mais importância — nunca sirva um PDF ou arquivo de texto enviado por usuário a partir de uma pasta com permissão de execução, e considere adicionar o cabeçalho Content-Disposition: attachment ao servir esses arquivos, forçando o download em vez da renderização inline no navegador.

Registrando e limitando a taxa de uploads

Além da validação de conteúdo, limite quantos uploads uma conta pode fazer em um intervalo de tempo (ex.: 10 uploads por hora) para mitigar abuso de armazenamento e tentativas automatizadas de bypass por força bruta de variações de payload. Registrar metadados de cada upload (conta, IP, hash do arquivo, resultado da validação) também ajuda a identificar contas comprometidas ou comportamento de bot rapidamente.

Erros comuns e soluções

Checklist de sanitização de uploads

• Validação de tipo real por magic bytes implementada (não apenas extensão/MIME do cliente).
• Limite de tamanho definido por tipo de upload (avatar, ticket, fórum).
• Arquivos renomeados com hash/UUID no momento do salvamento.
• Uploads armazenados fora da webroot ou em pasta sem permissão de execução.
• Servidor web configurado para negar execução de script na pasta de uploads.
• Imagens reprocessadas (GD/Imagick) antes do armazenamento final.
• Rate limiting e log de uploads por conta/IP implementados.

Com os uploads sanitizados, revise também os demais pontos de entrada de dados do seu painel — o tutorial de criação de servidor de MU Online cobre a base de infraestrutura sobre a qual essas proteções devem ser aplicadas.

Perguntas frequentes