Inyección SQL en PrestaShop vía parámetro de módulo: anatomía del ataque

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

La inyección SQL en un módulo PrestaShop es uno de los ataques más rentables contra el e-commerce, porque de un solo parámetro mal tratado puede salir la base de datos entera: pedidos, clientes y, en el peor de los casos, la puerta para colocar un skimmer. En este artículo desmontamos la anatomía del ataque paso a paso. Forma parte de nuestra guía pilar de seguridad de e-commerce y multi-CMS.

En PathSentinel atendemos incidentes en pymes y e-commerce, pero también en entornos exigentes como banca y comercios con datos de tarjeta, donde una SQLi no es un fallo teórico sino una brecha notificable.

Qué es una inyección SQL en un módulo PrestaShop

Ocurre cuando un módulo construye una consulta SQL concatenando directamente un valor que llega del usuario —un parámetro de URL, un campo de formulario, una cabecera— sin sanearlo. El atacante «rompe» la sintaxis de la consulta e introduce la suya. En PrestaShop el punto habitual son los controladores front y los endpoints AJAX del módulo, alcanzables por URL sin autenticación.

El código vulnerable típico

El patrón peligroso, simplificado, es este: un parámetro entra por la petición y se pega tal cual dentro de la sentencia.

• El módulo lee algo como id_categoria desde la petición.
• Lo inserta en una consulta con concatenación de cadenas, sin comillas de tipo ni escape.
• La base de datos ejecuta lo que el atacante haya inyectado, no lo que el desarrollador pretendía.

Anatomía del ataque, fase por fase

• 1. Descubrimiento: el atacante enumera controladores de módulos accesibles y prueba parámetros con caracteres de control (comilla simple, paréntesis) buscando un error SQL o un cambio de comportamiento.
• 2. Confirmación: usando técnicas booleanas o basadas en tiempo, confirma que la entrada altera la consulta aunque el sitio no muestre el error (SQLi ciega).
• 3. Extracción: mediante UNION o inferencia, lee tabla a tabla: ps_customer, ps_orders, ps_address. Ahí están los datos personales y de compra.
• 4. Escalada: en cadenas más graves —como la oleada que PrestaShop describió en su aviso de julio de 2022— la SQLi se combina con otras piezas para lograr ejecución de código y colocar un skimmer en el checkout. El detalle vive en PrestaShop Security.

El salto de «leer la base de datos» a «ejecutar código» es lo que convierte una SQLi en una brecha de datos de tarjeta con obligaciones ante el PCI Security Standards Council.

Por qué PrestaShop es especialmente sensible

El núcleo de PrestaShop ofrece herramientas correctas para consultar la base de datos con seguridad, pero muchos módulos de terceros no las usan. Es el mismo problema de fondo que explicamos en por qué los módulos de PrestaShop son la puerta de entrada nº1: código heredado, autores que ya no mantienen el producto y consultas construidas a mano.

Cómo blindar tus consultas

La defensa es conocida y eficaz; el problema es que no siempre se aplica. Reglas concretas para PrestaShop:

• Sanea toda entrada con las funciones del framework: pSQL() para cadenas y forzado de tipo ((int)) para identificadores numéricos. Un id siempre entero, sin excepción.
• Usa consultas parametrizadas / prepared statements siempre que sea posible, en lugar de concatenar.
• Valida por lista blanca: si un parámetro solo puede tomar ciertos valores (orden «ASC»/»DESC», nombres de columna), compáralo contra un conjunto permitido.
• Mínimo privilegio en la BD: el usuario de la aplicación no necesita permisos de administración del motor.
• Desactiva el modo desarrollador en producción para no filtrar errores SQL que guían al atacante.
• WAF por delante como capa de contención, nunca como sustituto de sanear el código.

Si sospechas que ya te ha pasado

Una SQLi explotada deja rastro: registros de peticiones anómalas, ficheros nuevos en carpetas de módulos, JavaScript extraño en el checkout. Si algo no cuadra, verifica el estado de tu tienda con nuestra guía ¿tu PrestaShop está hackeado? Cómo comprobarlo en 2 minutos. Comprender la inyección SQL vía parámetro de módulo es el primer paso para no ser la próxima víctima de una técnica que, desgraciadamente, sigue funcionando.