How to sanitize user uploads on your MU Online server's website and panel

The website and panel of a MU Online server almost always accept some kind of user upload — profile avatar, support ticket attachment, forum post image. Without proper handling, every one of these entry points is an open door to webshell uploads, site defacement, or full compromise of the web server. This tutorial covers upload sanitization end to end: real type validation, size limits, secure renaming, storage outside the webroot, and image reprocessing, with practical examples in PHP, the language most commonly used in MU server panels.

Why file upload is one of the most common attack vectors

MU Online server panels are often built quickly, focused on functionality (ranking, shop, voting) with little attention to upload security. A poorly validated "upload avatar" or "attach screenshot to ticket" field lets an attacker send a .php file disguised as an image, and if that file lands in a public folder with execution permission, it gains code execution directly on the server — the worst-case scenario, even worse than an isolated SQL injection, because it grants full control of the machine.

The fundamental mistake: trusting the file extension

The most common and most flawed validation in panels is checking only the extension of the uploaded file's name. An attacker can name the file shell.php.jpg, manipulate the MIME type field sent by the browser (which is client-controlled and therefore untrustworthy), or use double-unicode techniques to bypass naive filters. The filename's extension is metadata, not proof of the real content.

Validating the file's real type by content (magic bytes)

Reliable validation checks the file's first bytes (binary signature), not the name or the MIME header sent by the client. In PHP, the finfo_file function (Fileinfo extension) reads the file's actual content:

<?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.');
}

This check should be the first barrier, before any other validation, because it prevents a file with a payload disguised as an image from reaching later processing steps.

Limiting file size

Besides the limits configured in PHP (upload_max_filesize, post_max_size), validate the size explicitly in the application code, since server limits that are misconfigured or absent in development environments don't protect production on their own.

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

Renaming the file at save time

Never preserve the original name uploaded by the user. Names like ../../../var/www/config.php (path traversal) or names duplicated between different users are real risks. Generate a new identifier, typically a hash or UUID, and pair it with the validated extension (not the original upload extension):

<?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;

Storing uploads outside the webroot

Even with rigorous validation, defense in depth recommends saving uploaded files outside the web server's public folder (webroot), or in a folder explicitly configured with no script execution permission. If a malicious file escapes all validation, it still won't be executable directly via URL.

Recommended structure:
/var/www/muweb/           <- public webroot (Apache/Nginx points here)
/var/data/uploads/         <- outside the webroot, real uploads live here
/var/www/muweb/serve.php   <- script that reads from /var/data/uploads/ and serves the image

serve.php (or an equivalent route) reads the file from the protected directory and delivers it to the browser with the correct Content-Type, never exposing the real storage path or allowing the file to be accessed as a script.

Configuring the web server to deny execution in the upload folder

As an additional layer, even if uploads end up inside the webroot due to some infrastructure limitation, disable script execution in that folder specifically. In Apache, via .htaccess in the uploads folder:

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

In Nginx, the equivalent is making sure the uploads folder's location block doesn't hand files off to PHP-FPM, serving them only as static files.

Reprocessing images to remove hidden payloads

A known attack technique uses "polymorphic images" — files that are simultaneously a valid .jpg and a valid script, depending on how they're interpreted. Reopening the image with a processing library and saving it again (even without changing visual quality) rebuilds the file from scratch, eliminating any payload embedded outside the image's standard structure:

<?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);
}

Applying the same rules to non-image attachments

Support ticket attachments sometimes need to accept other formats (PDF, log text). For these cases, magic-byte validation still applies, but defense in depth becomes even more important — never serve a user-uploaded PDF or text file from a folder with execution permission, and consider adding the Content-Disposition: attachment header when serving these files, forcing a download instead of inline rendering in the browser.

Logging and rate-limiting uploads

Beyond content validation, limit how many uploads an account can make within a time window (e.g., 10 uploads per hour) to mitigate storage abuse and automated brute-force attempts at payload variation bypasses. Logging metadata for each upload (account, IP, file hash, validation result) also helps quickly identify compromised accounts or bot behavior.

Common errors and fixes

Upload sanitization checklist

• Real type validation via magic bytes implemented (not just client extension/MIME).
• Size limit defined per upload type (avatar, ticket, forum).
• Files renamed with hash/UUID at save time.
• Uploads stored outside the webroot or in a folder with no execution permission.
• Web server configured to deny script execution in the uploads folder.
• Images reprocessed (GD/Imagick) before final storage.
• Rate limiting and upload logging by account/IP implemented.

With uploads sanitized, it's also worth reviewing the other data-entry points in your panel — the MU Online server setup tutorial covers the infrastructure foundation these protections should be built on.

Frequently asked questions