Seguridad de módulos PrestaShop: el vector de ataque que más compromete tiendas online
Por Kike Gandia · Co-Fundador y CEO, OSCP
Los módulos de terceros en PrestaShop son el equivalente a los plugins de WordPress: código PHP de terceros ejecutado con privilegios completos sobre la instalación. La diferencia es que el ecosistema de módulos PrestaShop tiene un historial de vulnerabilidades críticas con exploits públicos activos que han comprometido miles de tiendas, muchas sin que sus propietarios lo supieran.
Vulnerabilidades más habituales en módulos PrestaShop
SQL Injection: El patrón más frecuente en módulos PrestaShop con historial de CVEs. Los módulos que aceptan input del usuario y lo pasan directamente a consultas de base de datos sin sanitización son explotables para extraer datos de clientes, credenciales o información de pedidos.
XSS almacenado en el back-office: Módulos que permiten a un atacante sin autenticación (o con privilegios bajos) inyectar JavaScript en el panel de administración, comprometiendo la sesión de cualquier administrador.
Subida de ficheros sin validación: Módulos de importación, personalizadores de producto o gestores de documentos que permiten subir archivos PHP camuflados como imágenes o documentos.
Endpoints de controlador sin autenticación: Muchos módulos registran controladores accesibles vía URL que ejecutan acciones administrativas sin comprobar si el usuario está autenticado.
Módulos con historial de vulnerabilidades activas
PrestaShop tiene un historial documentado de vulnerabilidades críticas en módulos de amplio uso: módulos de pago, módulos de importación de productos, módulos de newsletter y módulos de personalización. En varios casos los exploits fueron públicos durante semanas antes de que los autores publicaran parches, y muchas tiendas siguen con versiones vulnerables meses después.
La revisión sistemática de módulos instalados contra bases de datos de CVEs (Friends of Presta, NVD) es el primer paso de cualquier auditoría de seguridad PrestaShop.
Módulos custom y desarrollos a medida
Los módulos desarrollados a medida para integraciones específicas —ERP, CRM, pasarelas de pago locales, exportadores de datos— raramente han pasado por una revisión de código de seguridad. Son código PHP ejecutado en producción con acceso completo a la base de datos y al sistema de ficheros, sin ninguna garantía de calidad de seguridad.
La auditoría de módulos custom incluye análisis estático del código buscando patrones inseguros y pruebas de intrusión sobre los endpoints que exponen.
Cómo decidir si un módulo se parchea, se sustituye o se elimina
Un inventario con CVEs no sirve de nada si después nadie decide qué hacer con cada línea. Estas son las decisiones razonables según la situación.
| Situación | Decisión razonable | Por qué |
|---|---|---|
| El autor ha publicado parche | Actualizar y verificar en staging antes de producción | Es el camino más corto y el único que cierra el fallo de raíz |
| Módulo sin soporte y con exploit público | Sustituir por una alternativa mantenida | Sin autor activo no va a llegar ningún parche |
| Módulo que ya no se usa pero sigue instalado | Desinstalar y borrar del disco | Un módulo desactivado puede seguir sirviendo sus controladores si los ficheros siguen ahí |
| El fallo está en un módulo a medida vuestro | Corregir y revisar el resto del módulo | Los patrones inseguros rara vez aparecen una sola vez en el mismo código |
| Módulo crítico para el negocio y sin alternativa | Aislar: regla específica en el WAF y revisión del código | Compra tiempo mientras se busca la sustitución, no la sustituye |
La fila que más sorpresas da es la tercera: desactivar un módulo desde el back-office no siempre impide que sus ficheros sigan siendo accesibles por URL. Si no se usa, se borra.
Indicios de que la tienda ya está comprometida
En una parte de las auditorías de PrestaShop el hallazgo no es una vulnerabilidad pendiente de explotar, sino una que ya se explotó hace meses. Estos son los indicios que conviene comprobar antes de nada.
- Ficheros PHP nuevos dentro de /modules/ o de /override/ que no corresponden a ningún despliegue.
- Overrides de clases del core que nadie del equipo recuerda haber creado.
- Empleados con perfil de administrador dados de alta fuera del proceso habitual, o con fechas de creación que no encajan.
- Tareas programadas o crons añadidos que invocan scripts propios.
- Ficheros con fecha de modificación reciente sin ningún despliegue en esa fecha.
- Scripts inesperados cargándose en la plantilla del checkout o en el pie de página.
- Cuentas de cliente con permisos o pedidos incoherentes.
Si alguno aparece, el orden correcto es conservar evidencia primero y limpiar después: si se borra el rastro antes de averiguar la vía de entrada, la reinfección es cuestión de semanas.
FAQ
¿Cómo sé si alguno de mis módulos actuales tiene una vulnerabilidad activa?
La forma más fiable es un análisis sistemático de todos los módulos instalados contra bases de datos de CVEs actualizadas. También hay servicios de monitorización continua que alertan cuando se publica una vulnerabilidad para un módulo instalado.
¿Los módulos del marketplace oficial de PrestaShop son más seguros?
Tienen controles de revisión básicos, pero siguen teniendo historial de vulnerabilidades. La validación del marketplace no es equivalente a una auditoría de seguridad. Módulos con miles de instalaciones y años de actividad han tenido CVEs críticos.
¿Con qué frecuencia hay que revisar los módulos?
El inventario contra bases de datos de vulnerabilidades tiene sentido de forma continua o al menos mensual, porque un módulo que hoy está limpio puede tener un exploit público mañana sin que vosotros hayáis tocado nada. La revisión en profundidad —código de los módulos a medida y pruebas sobre los endpoints que exponen— se repite cuando cambia el conjunto de módulos o tras un desarrollo relevante, no en cada ciclo.
¿Un WAF sustituye al parcheo de los módulos?
No. Un WAF puede frenar la explotación genérica de un fallo conocido y es una mitigación útil mientras se prepara la actualización, pero se apoya en firmas y en patrones: una variante del exploit, una petición codificada de otra forma o un fallo de lógica de negocio pasan sin que salte nada. Sirve para ganar tiempo, no para cerrar el ciclo.
¿Qué necesitáis para auditar nuestros módulos a medida?
El código fuente de esos módulos, una instalación de staging donde reproducir el comportamiento, cuentas de prueba de cliente y de empleado con los perfiles que existan, y saber qué integraciones externas toca cada módulo. El análisis combina revisión del código con pruebas sobre los controladores y endpoints que el módulo registra, porque un fallo en el código solo importa de verdad si es alcanzable.
¿Qué se entrega al terminar?
El inventario completo de módulos con su versión, su estado de mantenimiento y las vulnerabilidades conocidas asociadas; los hallazgos sobre el código a medida con su prueba de concepto; la decisión recomendada para cada módulo problemático (actualizar, sustituir, eliminar o aislar); y un plan de remediación ordenado por riesgo real, no por la puntuación teórica del CVE.