Uno de los consejos más habituales que se dan (yo también) sobre seguridad en WordPress es no usar el prefijo por defecto de WordPress para las tablas de la base de datos pero ¿de verdad este cambio mejora la seguridad de WordPress?
Ya sea desde la instalación o a posteriori (ver enlace del párrafo anterior), usar un prefijo distinto para las tablas de la base de datos es un consejo básico de seguridad en WordPress para evitar inyecciones SQL.
Como ya sabrás, WordPress por defecto usa el prefijo wp_nombretabla pero ¿realmente es una mejora de seguridad usar otro como mistablas_nombretabla? Vamos a ver los argumentos …
¿Qué es una inyección SQL?
Para empezar es bueno saber qué es exactamente una inyección SQL. Por resumir, una inyección SQL ofrece al atacante la posibilidad de inyectar código SQL a través de alguna vía de entrada que esté disponible para los visitantes (visible o no) y que pueda ejecutarlo desde el servidor de la base de datos, que en el caso de WordPress sería el servidor MySQL donde esté alojado.
Por ejemplo, imagina que que en vez de introducir una dirección de email en un formulario de registro el atacante introduce código SQL que hace una lista de todos los registros de la tabla wp_users, que es donde se guardan todos los datos de los usuarios registrados de un WordPress. Da miedito ¿no?
Si así fuera, una vez enviado el formulario, en vez de rechazar el código SQL, la web lo ejecuta y el servidor de la base de datos le entregaría el contenido de la tabla wp_users al atacante.
Una inyección SQL, o sea, la ejecución de código a través de una vía de entrada a una web es el resultado típico de un problema con el código de un formulario, un plugin, el tema o cualquier otro componente de la instalación de WordPress. Y es posible casi siempre debido a que la vía de entrada para los visitantes no se ha saneado, por lo que permite la introducción de código SQL.
Es básicamente eso. En una instalación típica de WordPress el atacante también podrá escribir en la base de datos, lo que es incluso más peligroso como veremos más adelante.
Como en todo, hay muchas variantes de posibles inyecciones SQL, algunas realmente rebuscadas, pero es bueno que tengas una visión general de cómo funciona una inyección SQL, el impacto que puede tener si se lleva a cabo (leer o escribir en la base de datos) y, sobre todo, cómo se puede evitar.
Ahora vamos a ver cómo afecta esto a una instalación típica de WordPress y si un cambio en el prefijo de la base de datos influye a la hora de evitar inyecciones SQL ¿te parece?
Nombres y tablas de la base de datos de WordPress
Ya hemos visto en varias ocasiones cuales son las tablas de la base de datos de WordPress y para lo que sirve cada tabla, pero nunca sobra un nuevo repaso, y para lo que estamos hablando hoy nos viene de perla un recordatorio.
Básicamente, WordPress instala por defecto 11 tablas que, si no lo modificas, tendrán el prefijo wp_, así que si no has hecho modificaciones serán estas:
- wp_commentmeta
- wp_comments
- wp_links
- wp_options
- wp_postmeta
- wp_posts
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
- wp_usermeta
- wp_users
Si entiendes algo de inglés, solo viendo los nombres de las tablas puedes adivinar fácilmente qué se almacena en cada tabla. Por ejemplo, es fácil imaginar que en la tabla wp_comments se almacenan los comentarios o que en wp_options es donde están los ajustes ¿no?
Explotando una inyección SQL en WordPress
Vamos a adentrarnos en los reinos de Mordor así que elige tu mejor arma y confía en la comunidad del anillo (o en la de WordPress) jeje
Imagina que uno de los plugins que tienes instalado en tu WordPress es vulnerable a una inyección SQL, algo que no es raro, es la vía más frecuente de vulnerabilidades. Un atacante que te tenga ganas lo primero que haría sería escanear tu instalación de WordPress con herramientas como WPScan para tener la lista de los plugins que tienes instalados, incluso los desactivados. Si al ver la lista detecta que uno de ellos es vulnerable a inyecciones SQl ya tendrá la mitad del trabajo hecho, por no decir la mayor parte.
Lo siguiente que haría sería explotar la inyección SQL para lo que ejecutaría unos códigos como los siguientes, los habituales para crear manualmente un administrador en la base de datos de WordPress, ahí es nada:
INSERT INTO `wordpressdatabase`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, `user_email`, `user_status`, `display_name`) VALUES ('1000', 'tempuser', MD5('Str0ngPa55!'), 'tempuser', 'support@wpwhitesecurity.com', '0', 'Temp User'); INSERT INTO ` wordpressdatabase`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1000', 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}'); INSERT INTO ` wordpressdatabase`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1000', 'wp_user_level', '10');
¿Qué hacen esos códigos? Pues nada más y nada menos que el atacante puede crear un usuario WordPress con privilegios de administrador en tu web, con lo que obtendrá de inmediato acceso al escritorio de tu WordPress con acceso total.
En otras ocasiones el atacante no solo crea un nuevo usuario administrador sino que además cambia la contraseña del actual y, de paso, te deja a ti sin acceso, un síntoma que cuando lo veas ya tardas en reaccionar.
¿Por qué el atacante puede crear un administrador?
Sabiendo de antemano que tu web está hecha con WordPress y que es vulnerable a inyecciones SQL debido a algún plugin vulnerable o lo que sea que haya visto, el atacante solo necesita conocimientos básicos de configuración de la base de datos de WordPress, algo totalmente documentado en la misma web de WordPress.org.
Adivinando nombres de tablas de la base de datos
Si el prefijo de la base de datos de WordPress del sitio es el definido por defecto, o sea wp_, el atacante puede fácilmente ejecutar código y leer o escribir información en las tablas.
Si cambias el prefijo de la base de datos de WordPress, por ejemplo a MordorX25_, el atacante no podrá leer o escribir en la base de datos tan fácilmente ya que no conoce los nombres de las tablas. Esto es así incluso aunque haya realizado la inyección SQL y el código sea explotable, pues no tendrían efecto alguno al no encontrar un objetivo sobre el que actuar.
Sí, cambiar el prefijo de las tablas de la base de datos de WordPress mejora la seguridad en WordPress
La – buena – idea de cambiar el prefijo de las tablas de la base de datos de WordPress es antigua, de hecho desde las primeras versiones de WordPress, para evitar inyecciones SQL que pudiesen crear usuarios e inyectar spam o malware. El único modo de pararlos rápidamente era cambiar los nombres por defecto de las tablas.
¿Significa esto que estoy a salvo solo cambiando el prefijo de las tablas de la base de datos de WordPress?
Por supuesto que no. Cambiar el prefijo de las tablas de la base de datos de WordPress es una muy buena medida de seguridad, y frena infinidad de ataques a la base de datos, pero no es la única forma en que pueden entrar en tu sitio.
Aunque la mayoría de las veces los culpables de un ataque a WordPress son plugins mal programados o sin actualizar, la realidad es que se puede conseguir acceso a una instalación de WordPress de otros modos, por ejemplo mediante ingeniería social, robando contraseñas y cualquier otro método que imagines. Todo dependerá del interés que tu sitio provoque en los posibles atacantes, y con la plaga de spammers que nos invade nadie está seguro 100%.
Así que, además de cambiar el prefijo de las tablas de la base de datos, aplica estas 15 reglas para tener un WordPress a prueba de bombas, serás más feliz.
Con el lanzamiento de la beta 1 de 
