Ataques de inyección SQL en WordPress: cómo proteger tu sitio

Los ataques de inyección de base de datos o inyección SQL (SQLi) se encuentran entre las amenazas de seguridad más comunes en el entorno de WordPress, ocupando un lugar destacado en los informes anuales de seguridad de WordPress.

Dado que son tan comunes y las vulnerabilidades que los hacen posibles están muy extendidas, comprenderlos y tomar medidas para prevenirlos puede ser abrumador al principio. Este artículo intentará facilitar el proceso explorando:

• Qué son las inyecciones SQL y cómo funcionan.
• Los diferentes tipos de inyecciones SQL.
• Qué ganan los hackers con las inyecciones SQL.
• Soluciones respaldadas por expertos para las inyecciones SQL.

Si eso te suena bien, empecemos.

¿Qué es un ataque de inyección SQL en WordPress?

SQL es un lenguaje de programación utilizado para gestionar bases de datos relacionales. Todos los sitios de WordPress utilizan bases de datos relacionales y gestores de bases de datos relacionales como MySQL, MariaDB y AuroraDB.

Las inyecciones SQL son usos maliciosos de SQL para obtener acceso a información en el backend que debería quedar oculta al público. Las inyecciones SQL en WordPress consisten en hackers que escriben comandos SQL en campos de entrada de usuario con la intención de ingresar a sitios web. Los campos de entrada de usuario más comunes que los hackers utilizan para inyectar comandos SQL incluyen casillas de inicio de sesión, casillas de búsqueda o campos de registro.

Debido a la forma en que las inyecciones SQL explotan vulnerabilidades en los campos de entrada de usuario, en algunos casos, pueden ser similares a los ataques cross-site scripting (XSS), otra amenaza cibernética común en el ecosistema de WordPress.

¿Cómo funcionan las inyecciones SQL en WordPress?

Los hackers realizan ataques de inyección SQL interfiriendo con las consultas que una aplicación (en este caso, un sitio web de WordPress) hace a su base de datos. Una consulta de base de datos es una solicitud de la información en la base de datos.

Una de las formas más comunes en que los hackers inyectan comandos SQL maliciosos es a través de campos de entrada como los formularios de nombre de usuario y contraseña. Un atacante puede, por ejemplo, introducir un nombre de usuario válido para el cual no tiene la contraseña y luego enviar un comando SQL en el campo Contraseña de la siguiente manera:

En lugar de ingresar la contraseña, el hacker puede introducir el siguiente comando SQL:

'OR username username_123 -- 

Tenga en cuenta que después del -- hay un espacio en blanco esencial para que este comando funcione.

Este comando modifica la consulta para indicarle a la base de datos que permita a este usuario iniciar sesión al coincidir el nombre de usuario username_123 con su contraseña correspondiente (la forma tradicional de iniciar sesión) o simplemente ingresando el nombre de usuario correcto y haciendo clic en Iniciar sesión. Este comando hace que el campo Contraseña sea irrelevante porque el sitio web permitirá que el usuario inicie sesión simplemente escribiendo un nombre de usuario válido, sin importar lo que esté en el campo Contraseña.

Sin embargo, este ataque no funcionaría en sitios web que encriptan sus contraseñas en lugar de pasarlas como texto plano. Para esos casos, un hacker puede usar solo el campo Username, ingresando el siguiente comando SQL (con un espacio en el final):

username_123’ -- 

El hacker luego escribiría cualquier cosa en el campo Contraseña ya que el comando SQL en el campo Username hace que la contraseña, una vez más, sea irrelevante.

Estos son dos ejemplos sencillos de los muchos métodos que los hackers pueden usar para entrar en sitios web al ingresar comandos SQL maliciosos en campos de entrada vulnerables. Los administradores de sitios web con conocimientos toman medidas de seguridad para prevenir estos ataques, pero los propietarios de sitios web no técnicos pueden no ser conscientes de esta vulnerabilidad, abriendo la puerta a más ataques.

Independientemente del método, las inyecciones SQL engañan a las bases de datos que no validan la entrada del usuario para dar a los hackers información destinada a permanecer privada.

Ahora que entendés cómo los hackers pueden fácilmente vulnerar sitios web no asegurados, exploremos los diferentes tipos de ataques de inyección SQL.

Tipos de ataques de inyección SQL en WordPress

Inyecciones SQL de banda directa o clásicas

Las inyecciones SQL de banda directa o clásicas son ataques de inyección SQL que utilizan el mismo canal para iniciar el ataque y extraer la información que desean. Por ejemplo, un hacker puede infiltrarse en un sitio utilizando comandos SQL en un navegador. Los resultados se mostrarán en el mismo navegador si utilizan una inyección SQL de banda directa.

Existen dos subtipos comunes de inyección SQL de banda directa.

Inyecciones SQL basadas en errores

En estos ataques de banda directa, los hackers ingresan consultas que producen un error en la base de datos. Por ejemplo, sus comandos SQL podrían contener una sintaxis deliberadamente incorrecta que cause una respuesta de error.

Basándose en los datos que recopilan de los mensajes de error, los hackers pueden obtener información sobre la estructura de la base de datos o idear formas de acceder sin autorización. Con ataques SQL basados en errores, los hackers pueden enumerar parcial o completamente una base de datos (extraer datos disponibles).

Inyecciones SQL basadas en UNION

En SQL, la declaración SELECT selecciona datos de una base de datos, almacenándolos en una tabla de resultados llamada “conjunto de resultados”. En el caso de una base de datos de WordPress, el conjunto de resultados puede incluir datos relacionados con plugins, comentarios, nombres de usuario, contraseñas, etc. La declaración UNION combina los datos del resultado de dos o más declaraciones SELECT en un solo conjunto de resultados.

Los ataques SQL basados en UNION utilizan la declaración UNION para realizar consultas que resultan en una combinación de tablas de la base de datos del sitio web como respuesta HTTP. Los hackers pueden usar este método para extraer información valiosa.

Inyecciones SQL inferenciales o de ciegas

Durante los ataques SQL de banda directa, los hackers pueden enviar una consulta y recibir una respuesta en el mismo canal, como el navegador que están utilizando.

En los ataques SQL “ciegos” o inferenciales, los hackers no reciben información directamente de la base de datos. Aun así, pueden monitorear la respuesta de la aplicación a la consulta que enviaron y obtener información de ella. Este tipo de ataque SQL también tiene dos subtipos.

Inyecciones SQL ciegas de Booleano

Los hackers envían una consulta SQL y observan la respuesta de la base de datos. El contenido de la respuesta HTTP a la consulta varía dependiendo de si la consulta devolvió un Booleano true o false.

Aunque la base de datos no devolvió explícitamente datos al hacker, este puede inferir si la consulta (como la longitud de una entrada de base de datos) era true o false en función del contenido de la respuesta HTTP. Al probar con múltiples consultas que indagan información sobre la base de datos, los hackers pueden lentamente enumerarla.

Inyecciones SQL ciegas basadas en tiempo

Con este método, los hackers también quieren saber si una consulta devolvió un Booleano true o false, pero en este caso lo hacen midiendo el tiempo que tarda la respuesta en llegar. Para lograr esto, envían una consulta que obliga a la base de datos a esperar un número específico de segundos para responder.

Dependiendo de si la respuesta HTTP llegó de inmediato o con un retraso de unos segundos, los hackers pueden determinar si era verdadero o falso. Pueden utilizar este método para enumerar la base de datos lentamente.

Inyecciones SQL fuera de banda

Este tipo de inyecciones SQL son menos comunes y se usan como alternativa a los tipos anteriores. Los hackers las utilizan típicamente cuando no pueden recibir respuestas de la base de datos por el mismo canal a través del cual están atacando. En su lugar, ordenan a una aplicación que envíe datos a una ubicación remota, como un servidor al que el hacker tiene acceso.

Los ataques SQL fuera de banda solo funcionan cuando el hacker puede acceder a un servidor con comandos que generan solicitudes DNS y HTTP desde otros servidores, una característica común en servidores SQL populares como Microsoft SQL Server y Oracle Database.

Al hacer solicitudes DNS y HTTP, los hackers pueden transferir información sensible desde la base de datos de la víctima a su servidor.

¿Qué pueden ganar, robar o lograr los hackers con ataques de inyección SQL en WordPress?

Los hackers tienen varias razones para realizar ataques de inyección SQL. Los datos más comunes a los que pueden acceder incluyen los siguientes:

• Información privada sobre la estructura de la base de datos.
• Información corporativa sensible como propiedad intelectual y secretos comerciales.
• Información personalmente identificable (IPI) sobre los usuarios del sitio web.
• Listas de nombres de usuario y contraseñas.
• Detalles confidenciales del consumidor.
• Información sobre la versión y otros detalles del software de gestión de bases de datos.

Si su ataque SQL les otorga acceso administrativo directo con credenciales de inicio de sesión robadas, los hackers podrían:

• Manipular el contenido de la base de datos.
• Eliminar la base de datos parcial o completamente.
• Bloquear el acceso a los datos de la base de datos para otros usuarios.
• Hacer pública la información privada.
• Anular y manipular transacciones monetarias.
• Manipular saldos financieros.

Esto podría dejar un impacto duradero en el sitio web y las marcas detrás de él. Por ejemplo, supongamos que la marca cumple con leyes de protección de información personal como el GDPR de la Unión Europea. En ese caso, podrían enfrentar multas debido a una violación de seguridad causada por inyecciones SQL.

¿Cómo proteger tus sitios de WordPress de los ataques de inyección de base de datos?

Los expertos consideran que las vulnerabilidades de inyección SQL son graves debido a su potencial para interrumpir una aplicación de WordPress. El hecho de que también estén muy extendidas no mejora la situación.

De acuerdo con el informe de seguridad de Wordfence de 2022 sobre WordPress, las vulnerabilidades de inyección SQL fueron la cuarta categoría más común de vulnerabilidades divulgadas durante el año. Además, el informe de seguridad de Sucuri de 2021 determinó que plugins populares con cientos de miles o millones de instalaciones, como WooCommerce, All In One SEO, y WP Statistics, tenían vulnerabilidades de inyección SQL que sus respectivos desarrolladores eventuales parchearon.

Puede ser difícil proteger tu sitio de ataques de inyección SQL porque hay muchas vías para que los hackers exploten, pero los expertos han ideado varias estrategias.

Sentencias preparadas

Las sentencias preparadas o consultas parametrizadas son a menudo consideradas la forma más efectiva de evitar ataques SQL. El problema fundamental que causa la inyección de código SQL malicioso en campos de entrada es que mezclan código y datos, engañando a las bases de datos vulnerables para compartir información confidencial.

Las sentencias preparadas aseguran que el código SQL se envíe al servidor de la base de datos y se analice por separado de los datos, lo que hace más difícil o imposible que un hacker inyecte código SQL malicioso. También hacen que la base de datos trabaje más eficientemente porque pueden usarse repetidamente sin recompilar.

Es la primera y más efectiva medida que los administradores de bases de datos deben tomar para prevenir ataques de inyección SQL.

Procedimientos almacenados

Los procedimientos almacenados son una secuencia de instrucciones que se pueden almacenar en la base de datos para su reutilización posterior. A menudo se crean para manejar secuencias de consultas que se aplican con frecuencia al modelo de la base de datos, ejecutándolas siempre que sea necesario.

Los procedimientos almacenados pueden ser tan efectivos como las sentencias preparadas cuando no incluyen generación de SQL dinámico no seguro. En este sentido, cumplen un rol similar a las sentencias preparadas, pero la principal diferencia es que las sentencias preparadas no pueden almacenarse mientras que los procedimientos almacenados sí.

No todos los sistemas de gestión de bases de datos permiten procedimientos almacenados, por lo tanto, su implementación depende de si tu sistema admite esta característica. Sistemas de gestión populares como los de Microsoft y Oracle los soportan.

Escanea tu sitio web a menudo

Existen pruebas de vulnerabilidad a inyecciones SQL en línea que podés ejecutar en tu sitio web (algunas de ellas son solo premium). Estas pruebas te darán una visión general de tus vulnerabilidades actuales junto con descripciones más detalladas de los riesgos que corre tu sitio web y cómo corregir sus fallas de seguridad.

Validación o saneamiento de entradas

Otra medida que debe usarse en combinación con las sentencias preparadas es la validación de entradas, que consiste en escribir código de una manera que identifique las entradas de usuario maliciosas, el método principal detrás de las inyecciones SQL.

Los expertos consideran que la mejor forma de aplicar la validación de entradas es aplicando la validación de “lista preferida” o “lista blanca”. Con este enfoque, la entrada del usuario se compara estrictamente con un conjunto de entradas conocidas, válidas y aprobadas. Si la entrada del usuario no se ajusta a la lista blanca de entradas, se rechaza.

Aunque la validación de entradas en lista blanca es una práctica recomendada, todavía puede ser vulnerable a lagunas y exploits, dada la dificultad de mapeo de todas las posibles entradas legales. Además, una validación de entradas mal aplicada puede interferir en la experiencia del usuario al generar muchos falsos positivos.

Es mejor combinarla con sentencias preparadas.

Escapando la entrada del usuario

“Escapar” la entrada del usuario implica usar una técnica (generalmente agregando un caracter antes de la cadena proporcionada por el usuario) para evitar que la entrada del usuario sea interpretada como código en lugar de una cadena de texto. Recordá que los hackers ingresan comandos SQL en campos de entrada de usuario para eludir la seguridad.

Al escaparlo, cualquier cosa que el usuario ingrese siempre se convierte en texto y nunca se interpreta como un comando SQL. Esto debería ocuparse de las inyecciones SQL de una vez por todas, pero hay muchas maneras en que los hackers pueden eludir las técnicas de escape (que varían dependiendo del sistema de gestión de bases de datos), por lo que nunca deben ser la única opción.

En última instancia, escapar la entrada del usuario es una forma de hacer lista negra, lo opuesto a las técnicas recomendadas de lista blanca que los expertos consideran una práctica recomendada, por lo que no debería ser tu única opción.

Prevení ataques de inyección SQL en WordPress en tu sitio

Hay mucho más para explorar sobre los ataques de inyección SQL, pero este artículo te ha introducido a algunos puntos básicos que deberías conocer.

Las inyecciones SQL son una vulnerabilidad común en sitios web y plugins de WordPress, por lo que proteger tu sitio contra ellas puede ser un desafío. Pero si sabés cómo operan y seguís nuestras recomendaciones, tu sitio estará mucho más seguro y protegido de las formas más comunes de inyecciones SQL.

Si encontraste útil este artículo, leé nuestro blog para obtener más información, guías y consejos sobre WordPress.