Pentesting Magento y Adobe Commerce: cómo se analiza la seguridad de una tienda enterprise
Por Kike Gandia · Co-Fundador y CEO, OSCP
Un pentesting de Magento evalúa la seguridad de la tienda simulando el comportamiento de un atacante que conoce la plataforma: las rutas por defecto, las APIs expuestas, los patrones de vulnerabilidad habituales en extensiones de terceros y los flujos de negocio que pueden manipularse. Es un análisis ofensivo real, no un escáner de versiones.
Fase 1: Reconocimiento específico de Magento
La enumeración en Magento incluye: detección de la versión exacta (Magento 1 vs Magento 2, Open Source vs Adobe Commerce) y su nivel de parcheo, identificación de la URL del panel de administración (que muchas tiendas dejan en /admin), enumeración de extensiones activas por fingerprinting de rutas y assets, y detección de versiones de extensiones a través de ficheros de módulo accesibles.
Pruebas sobre el panel de administración
El panel de administración de Magento es el objetivo de mayor valor. Las pruebas incluyen: fuerza bruta y credential stuffing (con o sin protección de rate limiting), detección de ausencia de MFA, intentos de bypass de autenticación en extensiones que modifican el flujo de login, y revisión de permisos de roles de administrador para identificar escaladas de privilegio entre roles con acceso limitado.
Análisis de extensiones y código custom
Las extensiones de Magento son módulos PHP complejos con acceso completo a la base de datos, el sistema de ficheros y las APIs internas de la plataforma. El análisis cubre: contraste de versiones con historial de CVEs conocidos, revisión de código en módulos custom buscando SQLi, XSS, SSRF, deserialización insegura y inyección de comandos, y análisis de la gestión de permisos en endpoints de API registrados por extensiones.
Pruebas de APIs REST y GraphQL
Magento 2 expone una API completa (REST y GraphQL) que es el backend de muchas integraciones headless y aplicaciones móviles. Las pruebas incluyen: enumeración de endpoints sin autenticación, pruebas de autorización (acceso a recursos de otros clientes), mass assignment en creación y modificación de recursos, y pruebas de inyección en parámetros de filtrado y búsqueda.
Fallos de lógica de negocio propios de una tienda
Los fallos que más dinero cuestan en Magento no suelen ser inyecciones, sino errores de lógica: la aplicación funciona exactamente como se programó, pero se programó mal. Ningún escáner los encuentra, porque para verlos hay que entender el flujo de compra.
Lo que se prueba en esta parte: si los cupones se pueden acumular o reutilizar más allá de su límite, si el total se recalcula de verdad en servidor después de aplicar reglas de carrito y de catálogo, si una cantidad negativa o un decimal inesperado alteran el importe, si los precios de productos configurables y de packs se pueden manipular desde la petición, si el redondeo y el cambio de moneda dejan un margen explotable, si el stock se reserva de forma que permita agotar el inventario sin comprar, y si los pedidos de un cliente son accesibles para otro por identificador consecutivo o mediante la función de repetir pedido.
Caja negra, caja gris y revisión de código: qué encuentra cada enfoque
La pregunta que más condiciona el resultado no es la herramienta, sino cuánta información se da al equipo que prueba.
| Enfoque | Qué necesita de tu parte | Lo que sí encuentra | Lo que se le escapa |
|---|---|---|---|
| Caja negra | Solo la URL | Panel expuesto, versiones sin parchear, fallos alcanzables sin cuenta | Lógica interna de los módulos a medida y permisos de rol |
| Caja gris | Cuentas de prueba de cliente y de cada rol de administrador | Escaladas entre roles, fallos de autorización en la API, lógica del checkout | Fallos que solo se ven leyendo el código |
| Revisión de código | El repositorio de los módulos a medida | Inyecciones, deserialización insegura, secretos en el repositorio | Problemas de la configuración real del entorno |
Para una tienda con desarrollo propio, la combinación que mejor relación esfuerzo-hallazgos da es caja gris sobre staging más revisión de código de los módulos a medida. La caja negra pura sirve para medir la exposición, no para asegurar la tienda.
FAQ
¿El pentesting de Magento requiere acceso al código fuente?
No para el análisis de caja negra o caja gris. Si se quiere auditar el código de extensiones custom, se facilita el código fuente para el análisis estático complementario.
¿Se puede hacer el pentesting sin afectar a los pedidos reales?
Sí. Las pruebas que implican creación de pedidos, modificación de datos o inyecciones activas se realizan en un entorno de staging. Si no existe, ayudamos a configurarlo antes del análisis.
¿Qué necesitáis de nosotros para empezar?
Un entorno de staging equivalente a producción, cuentas de prueba de cliente y una por cada rol de administrador que exista, el inventario de extensiones instaladas con su versión, el código de los módulos a medida si se va a revisar, y una ventana acordada para las pruebas que generan carga. Con eso el trabajo arranca sin depender de nadie por vuestra parte durante la ejecución.
¿Qué se entrega al terminar?
Un informe ejecutivo para dirección, un informe técnico con cada hallazgo clasificado por criticidad y su prueba de concepto reproducible, el detalle de qué extensión o qué punto del código lo origina, y un plan de remediación ordenado por impacto. La reunión de cierre sirve para que el equipo de desarrollo entienda cada hallazgo antes de ponerse a corregir.
¿Afecta al rendimiento de la tienda?
Si se trabaja sobre staging, no afecta a la tienda real. Si parte del alcance tiene que ejecutarse en producción —por ejemplo, verificar la exposición del panel o las cabeceras—, se limitan a pruebas pasivas o de bajo impacto y se acuerda la ventana. Las pruebas que generan carga o crean pedidos nunca van contra producción sin acuerdo explícito.
Si seguimos en Magento 1, ¿tiene sentido auditarlo?
Tiene sentido, pero conviene saber qué se obtiene. Magento 1 ya no recibe parches oficiales, así que buena parte de los hallazgos del core no van a tener corrección disponible: el informe sirve para dimensionar el riesgo real, priorizar mitigaciones y sostener la decisión de migrar con datos en lugar de con intuiciones. Si la migración ya está decidida y con fecha, suele rendir más auditar el destino que el origen.