Auditoría de vulnerabilidades web para el sitio y el panel de tu servidor de MU Online

El sitio y el panel de control son, en la mayoría de los servidores privados de MU Online, la superficie de ataque más expuesta y menos protegida — mucho más que el propio GameServer, que generalmente ya recibió atención de seguridad del emulador. Un panel vulnerable permite el robo de cuentas, la manipulación de Zen/Cash, la filtración de datos de jugadores y, en casos graves, el acceso al servidor de base de datos entero. Este tutorial recorre una auditoría de vulnerabilidades web completa, cubriendo las fallas más comunes encontradas en sitios y paneles de este nicho, con pasos prácticos de identificación y corrección.

Por qué el sitio es el blanco más común

A diferencia del cliente del juego, que corre en la computadora del jugador y exige ingeniería inversa para ser atacado, el sitio permanece accesible públicamente las 24 horas, generalmente construido sobre PHP con frameworks anticuados, plugins de terceros nunca actualizados y, con frecuencia, scripts de panel de control (CMS de MU) copiados de foros sin revisión de código. Esta combinación de exposición pública y código poco auditado convierte al sitio en el punto de entrada preferido de los atacantes.

Alcance de la auditoría

Antes de empezar, define qué se va a probar: sitio institucional, panel de control de cuenta (registro, creación de personaje, votación), tienda de Cash/VIP con pago, área administrativa (panel de GM web), y cualquier API expuesta. Cada superficie tiene riesgos distintos — la tienda de pago, por ejemplo, exige atención redoblada por manejar datos financieros.

SQL Injection: la vulnerabilidad más común en el nicho

Los sitios de MU heredados frecuentemente arman queries por concatenación directa de strings provenientes del usuario:

// Código vulnerable — NUNCA hagas esto
$query = "SELECT * FROM accounts WHERE username = '" . $_POST['user'] . "'";

Un atacante puede enviar ' OR '1'='1 en el campo de usuario y evadir la autenticación, o peor, extraer toda la tabla de cuentas. La corrección es usar prepared statements en todas las consultas que reciben entrada del usuario:

// Código correcto
$stmt = $pdo->prepare("SELECT * FROM accounts WHERE username = ?");
$stmt->execute([$_POST['user']]);
$result = $stmt->fetch();

Audita todos los archivos PHP del sitio en busca de concatenación directa en queries SQL — herramientas como grep -r "SELECT.*\$_" . ayudan a localizar candidatos rápidamente para la revisión manual.

XSS (Cross-Site Scripting)

Campos como nombre de personaje, mensaje de foro, comentario de noticia o incluso nombre de guild, cuando se muestran sin escape en el HTML, permiten la inyección de scripts maliciosos que corren en el navegador de otros usuarios (robo de sesión, redirección maliciosa). Escapa siempre la salida con funciones como htmlspecialchars() en PHP antes de imprimir cualquier dato proveniente del usuario:

echo htmlspecialchars($personagem['nome'], ENT_QUOTES, 'UTF-8');

Prueba insertando <script>alert(1)</script> en todos los campos de entrada del sitio y observa si la alerta se ejecuta al visualizar la página — si se ejecuta, el campo es vulnerable.

Fallas de autenticación y sesión

Exposición de datos sensibles

Verifica si el sitio expone, incluso sin querer, información que no debería ser pública: mensajes de error de PHP con la ruta completa del servidor (display_errors activado en producción), archivos de configuración (config.php) accesibles directamente por la URL, backups de base de datos dejados en la carpeta pública, y logs con datos de cuenta accesibles sin autenticación.

; php.ini en producción — nunca dejes esto así
display_errors = On

En producción, define siempre display_errors = Off y registra los errores en un log privado, sin mostrarlos nunca en la pantalla del visitante.

CSRF (Cross-Site Request Forgery)

Las acciones sensibles del panel (cambiar contraseña, canjear código de recompensa, comprar ítem en la tienda) deben exigir un token CSRF único por sesión/formulario, validado en el servidor antes de procesar la acción. Sin esto, un atacante puede inducir al jugador ya conectado a ejecutar una acción sin saberlo, a través de un enlace o página maliciosa.

Subida de archivos maliciosos

Si el panel permite subir archivos (avatar de foro, imagen de guild, adjunto de soporte), valida rigurosamente el tipo real del archivo (no confíes solo en la extensión), limita el tamaño, renombra el archivo guardado con un nombre generado por el servidor (nunca uses el nombre original) y almacénalo fuera de la carpeta pública ejecutable, o al menos impide la ejecución de scripts en la carpeta de subida mediante la configuración del servidor web.

Probando con herramientas automatizadas

Herramientas gratuitas ayudan a cubrir lo básico antes de la revisión manual:

• OWASP ZAP: scanner de vulnerabilidades web gratuito, bueno para XSS, headers de seguridad ausentes y configuraciones débiles de TLS.
• sqlmap: identifica y explota SQL Injection automáticamente — úsalo solo en tu propio entorno, nunca contra sitios de terceros sin autorización.
• Mozilla Observatory: analiza los headers de seguridad (CSP, HSTS, X-Frame-Options) del sitio publicado.

Headers de seguridad HTTP

Configura los headers de seguridad en el servidor web (Nginx/Apache), reforzando la protección del navegador incluso si una falla pasa desapercibida en el código:

add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "default-src 'self'";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Estos headers mitigan el clickjacking, el MIME sniffing malicioso y fuerzan las conexiones HTTPS.

Priorizando las correcciones

Con la lista de vulnerabilidades encontradas, prioriza por impacto × facilidad de explotación: SQL Injection y fallas de autenticación van primero (pueden comprometer cuentas y la base de datos entera), seguidas de XSS y CSRF (comprometen sesiones individuales), y por último los headers ausentes y la exposición de información (aumentan la superficie pero exigen pasos adicionales del atacante).

Errores comunes y soluciones

Lista de verificación de auditoría de vulnerabilidades web

• Todas las queries SQL revisadas y migradas a prepared statements.
• Salida de datos de usuario escapada contra XSS en todo el sitio.
• Contraseñas almacenadas con hash fuerte (bcrypt/argon2) y salt automático.
• Sesiones con expiración y regeneración de ID tras el login.
• Tokens CSRF implementados en formularios de acciones sensibles.
• display_errors desactivado en producción, logs privados configurados.
• Subida de archivos validada, renombrada y aislada de ejecución.
• Headers de seguridad HTTP configurados en el servidor web.
• Escaneo automatizado (OWASP ZAP) ejecutado y vulnerabilidades tratadas.

Después de cerrar las brechas del sitio, mantén la seguridad viva en el tiempo: programa revisiones recurrentes y conecta este proceso con la disciplina de gestión del servidor descrita en la guía de creación de servidor de MU Online, ya que la seguridad web es solo una capa de un proyecto que necesita mantenimiento continuo.

Preguntas frecuentes