Cómo prevenir SQL Injection en formularios legados del sitio de tu servidor de MU Online

Muchos sitios de servidores de MU Online funcionan sobre paneles PHP escritos hace años, adaptados de plantillas de la comunidad, con formularios de login, ranking, donación y recuperación de contraseña que nunca fueron auditados. Este tipo de código legado es el blanco más común de SQL Injection: un atacante inserta un fragmento de SQL malicioso en un campo de formulario y manipula la consulta para extraer contraseñas, crear cuentas administrativas o incluso eliminar tablas enteras. Este tutorial muestra cómo identificar los puntos vulnerables más comunes en estos paneles, corregirlos con prepared statements, y validar que la corrección realmente funcionó.

Cómo ocurre el SQL Injection en la práctica

La vulnerabilidad nace cuando la entrada del usuario se concatena directamente dentro de una cadena SQL. Un ejemplo clásico encontrado en paneles legados de MU:

// VULNERABLE - no hagas esto
$user = $_POST['username'];
$pass = $_POST['password'];
$query = "SELECT * FROM MEMB_INFO WHERE memb___id = '$user' AND memb__pwd = '$pass'";
$result = mysql_query($query);

Si un atacante envía en el campo de usuario el valor ' OR '1'='1' -- , la consulta final se convierte en SELECT * FROM MEMB_INFO WHERE memb___id = '' OR '1'='1' -- ' AND memb__pwd = '', que retorna la primera fila de la tabla — generalmente una cuenta administrativa — sin necesitar la contraseña correcta. Este es el ataque de bypass de login más común contra paneles de MU antiguos.

Dónde buscar: los formularios de mayor riesgo

No todos los formularios tienen el mismo riesgo. Prioriza la auditoría en este orden:

Paso 1 — Levantar todos los puntos de entrada

Haz un grep en el código fuente del panel buscando llamadas antiguas a la base de datos y concatenación de variables de request:

grep -rn "mysql_query\|mysqli_query" ./painel/ | grep '\$_'
grep -rn "\$_GET\|\$_POST\|\$_COOKIE" ./painel/ --include="*.php" | grep -i "select\|insert\|update\|delete"

Cada línea retornada es un candidato a punto vulnerable. En paneles legados de MU es común encontrar decenas de ocurrencias, especialmente en archivos como login.php, ranking.php, busca_char.php y recuperar_senha.php.

Paso 2 — Migrar de mysql_* a mysqli o PDO

La extensión mysql_* no soporta prepared statements nativos y fue eliminada de PHP desde la versión 7. Si el panel todavía usa esta extensión, migrar a mysqli con bind de parámetros es el primer paso obligatorio:

// SEGURO - con mysqli y prepared statement
$user = $_POST['username'];
$pass = $_POST['password'];

$stmt = $mysqli->prepare("SELECT * FROM MEMB_INFO WHERE memb___id = ? AND memb__pwd = ?");
$stmt->bind_param("ss", $user, $pass);
$stmt->execute();
$result = $stmt->get_result();

Con el parámetro vinculado vía bind_param, el valor enviado por el atacante nunca se interpreta como parte del comando SQL — siempre se trata como dato literal, sin importar el contenido.

Paso 3 — Corregir el formulario de búsqueda/ranking

Los formularios de búsqueda por nombre de personaje suelen usar LIKE con concatenación directa, un punto que a menudo se olvida corregir:

// VULNERABLE
$nome = $_GET['nome'];
$query = "SELECT * FROM Character WHERE Name LIKE '%$nome%'";

// SEGURO
$nome = $_GET['nome'];
$stmt = $pdo->prepare("SELECT * FROM Character WHERE Name LIKE :nome");
$stmt->execute(['nome' => '%' . $nome . '%']);

Nota que el comodín % se agrega en el valor del parámetro, no en la cadena de la consulta — esto preserva la protección del prepared statement.

Paso 4 — Manejar nombres de tabla y columna dinámicos con whitelist

Los prepared statements protegen valores, pero no protegen nombres de tabla o columna usados dinámicamente (por ejemplo, en un ranking que ordena por una columna elegida por el usuario). En ese caso, usa una whitelist explícita en lugar de bind:

$colunasPermitidas = ['Level', 'Resets', 'PkCount', 'Money'];
$ordem = $_GET['ordem'];

if (!in_array($ordem, $colunasPermitidas, true)) {
    $ordem = 'Level'; // valor predeterminado seguro
}

$query = "SELECT * FROM Character ORDER BY $ordem DESC LIMIT 100";

Nunca aceptes el nombre de la columna directamente del request sin esta validación contra una lista cerrada de valores posibles.

Paso 5 — Validar y normalizar tipos antes que nada

Además del prepared statement, valida el tipo esperado de cada campo antes de usarlo, como capa extra de defensa:

$id = $_GET['id'];
if (!ctype_digit($id)) {
    die('Parámetro inválido.');
}
$id = (int) $id;

Esto no reemplaza el prepared statement, pero reduce la superficie de ataque y evita que errores de la aplicación procesen tipos inesperados en otros puntos del código.

Paso 6 — Auditar la integración de pago/donación

Las páginas de donación frecuentemente reciben parámetros de retorno de pasarelas de pago (monto, referencia, estado) vía GET/POST y los usan directamente en actualizaciones de saldo. Garantiza que:

• El monto del crédito nunca provenga directamente del parámetro de la URL — confirma siempre el valor real con la API de la pasarela (webhook firmado), nunca confíes en lo que el navegador del usuario devuelve.
• La consulta de actualización de saldo del jugador use prepared statement con el valor validado del lado del servidor, no del request.
• Se mantengan logs de toda transacción de crédito para auditoría posterior.

Paso 7 — Probar la corrección

Después de corregir, prueba manualmente con payloads clásicos para confirmar que el comportamiento cambió:

Si cualquiera de estos payloads todavía altera el comportamiento esperado de la aplicación, la corrección no se aplicó correctamente en ese punto.

Paso 8 — Reducir la superficie con el principio del menor privilegio en la base de datos

Como capa adicional, garantiza que el usuario de base de datos usado por el panel PHP no tenga permiso de DROP, ALTER ni acceso a otras bases más allá de la necesaria:

CREATE USER 'painel_web'@'localhost' IDENTIFIED BY 'senha-forte-aqui';
GRANT SELECT, INSERT, UPDATE ON MuOnline.MEMB_INFO TO 'painel_web'@'localhost';
GRANT SELECT, INSERT, UPDATE ON MuOnline.Character TO 'painel_web'@'localhost';
-- Sin GRANT DROP, ALTER ni acceso a otras bases
FLUSH PRIVILEGES;

Incluso si una inyección pasa desapercibida en algún punto no auditado, este usuario restringido limita el daño posible.

Errores comunes y soluciones

Lista de verificación de auditoría de SQL Injection

• Todos los formularios de login, recuperación de contraseña y búsqueda revisados.
• Todo uso de mysql_query/concatenación directa migrado a prepared statements.
• Nombres de columna/tabla dinámicos validados por whitelist, nunca por bind directo.
• Valores financieros de donación validados vía API/webhook, nunca vía parámetro del request.
• Pruebas manuales con payloads clásicos ejecutadas tras cada corrección.
• Usuario de base de datos del panel restringido al mínimo de permisos necesarios.
• Logs de acceso revisados en busca de payloads sospechosos ya utilizados en el pasado.

Con el panel protegido contra SQL Injection, el siguiente paso natural es revisar también el acceso administrativo que gestiona esa misma base de datos — consulta la guía de creación de servidor de MU Online para revisar la infraestructura completa detrás del panel.

Preguntas frecuentes