Seguridad del checkout en Magento: Magecart, manipulación de precios y protección del proceso de pago
Por Kike Gandia · Co-Fundador y CEO, OSCP
El proceso de checkout es el componente más crítico de una tienda Magento desde el punto de vista de seguridad y negocio. Un fallo aquí puede significar robo de datos de tarjeta, fraude en pedidos o pérdida de confianza de clientes. Los atacantes lo saben y es donde concentran esfuerzos más sofisticados.
Riesgo Magecart: skimming de tarjetas en el checkout
Los ataques Magecart insertan JavaScript malicioso que captura datos de tarjeta introducidos por el usuario en el formulario de pago, antes de que lleguen a la pasarela. El vector de entrada más habitual es una extensión de terceros comprometida o desactualizada, un módulo con una vulnerabilidad de XSS que permite inyectar scripts, o una dependencia de CDN externa sin política CSP restrictiva.
La detección requiere análisis activo de todos los scripts con acceso al DOM del checkout, revisión del historial de integridad de ficheros del servidor y análisis de las cabeceras Content-Security-Policy.
Manipulación de precios y lógica de negocio
Magento calcula precios, descuentos y totales en el servidor, pero el proceso implica múltiples llamadas AJAX entre el navegador y la API. Las pruebas de lógica de negocio analizan: si es posible modificar el importe final manipulando parámetros de la solicitud, si los cupones de descuento tienen límites correctamente validados en servidor, si los precios de productos con opciones configurables pueden alterarse, y si las reglas de precio de catálogo aplican restricciones correctas por grupo de clientes.
Seguridad de integraciones con pasarelas de pago
Las pasarelas de pago en Magento se implementan como extensiones PHP con acceso a los datos de pedido y, en algunos casos, a los datos de tarjeta antes de tokenización. La auditoría de la integración de pago cubre: validación de la firma en callbacks y webhooks, manejo seguro de tokens de pago, ausencia de logging de datos sensibles en ficheros de log accesibles, y correcta gestión del flujo de error para evitar pedidos duplicados o pagos sin confirmación.
Qué exige PCI DSS sobre los scripts de la página de pago
La versión 4.0 del estándar dejó de tratar el control de los scripts del checkout como una buena práctica recomendable y lo convirtió en requisito exigible. En la práctica esto se traduce en dos obligaciones que afectan directamente a cómo está montada una tienda Magento.
La primera es mantener un inventario de todos los scripts que se cargan en la página de pago, con una justificación de negocio para cada uno y una autorización explícita: si nadie sabe por qué está ahí un script, no debería estar. La segunda es disponer de un mecanismo que detecte modificaciones no autorizadas en las cabeceras HTTP y en el contenido de la página de pago, y que alerte cuando se produzcan. Un skimming de tipo Magecart es precisamente eso: un script que aparece sin que nadie lo haya autorizado. Si una tienda procesa pagos con datos de tarjeta que pasan por su propio checkout, este es el punto del estándar que más trabajo técnico genera.
Dónde vive cada control del checkout y cómo se verifica
Casi todos estos controles se dan por hechos y casi ninguno se comprueba. Esta es la correspondencia entre el control, el sitio donde se configura y la prueba que demuestra que funciona.
| Control | Dónde se configura | Cómo se verifica |
|---|---|---|
| Inventario de scripts de la página de pago | Plantilla del checkout y gestor de etiquetas | Comparar los scripts cargados en producción con la lista autorizada |
| CSP con orígenes permitidos | Cabeceras del servidor web o del CDN | Intentar cargar un script no autorizado y comprobar que se bloquea |
| Integridad de recursos externos | Etiquetas de script del checkout | Verificar que cada recurso externo lleva su hash de integridad |
| Validación de firma en webhooks de pago | Módulo de la pasarela | Reenviar un callback manipulado y comprobar que se rechaza |
| Cálculo del importe en servidor | Reglas de carrito y de catálogo | Manipular el total en la petición y comprobar que se recalcula |
| Registro sin datos sensibles | Configuración de log del módulo de pago | Buscar números de tarjeta y tokens en los ficheros de log |
| Detección de cambios en la página de pago | Monitorización de integridad | Introducir un cambio controlado y comprobar que salta la alerta |
FAQ
¿Una política CSP estricta protege completamente frente a Magecart?
Es la medida de mitigación más eficaz, pero no es suficiente sola. CSP puede estar mal configurada (demasiado permisiva), puede tener excepciones para scripts necesarios del negocio, o el atacante puede explotar un script de primera parte para inyectar el código. La auditoría evalúa la CSP y valida su efectividad real.
¿Se pueden hacer pruebas de manipulación de precios sin generar pedidos reales?
Sí. Las pruebas se realizan en entorno de staging con datos de prueba. No se generan pedidos reales ni se procesan pagos durante el pentesting.
Sospecho que ya tengo un skimmer. ¿Por dónde empiezo?
Por no borrar nada. Antes de limpiar, conserva una copia del estado actual: ficheros, base de datos y registros del servidor, porque son la única evidencia de cómo entró el atacante y desde cuándo. Después compara los scripts que carga el checkout en producción con los que deberían estar, revisa los ficheros modificados recientemente sin despliegue asociado, busca administradores creados fuera de proceso y comprueba los overrides y las tareas programadas. Limpiar sin averiguar la vía de entrada garantiza una reinfección.
¿Se puede auditar el checkout en producción?
La parte de observación sí, y de hecho es la única forma de ver lo que carga el checkout real: scripts, cabeceras, CSP y comportamiento de la pasarela en modo de prueba. Lo que no se hace en producción son las pruebas de manipulación de precios ni las inyecciones activas, que van contra staging con datos de prueba y sin procesar pagos.
¿Un gestor de etiquetas en el checkout es un riesgo?
Es un riesgo de primer orden, porque permite inyectar JavaScript arbitrario en la página de pago sin pasar por el ciclo de despliegue ni por revisión de código, y normalmente con acceso de personas de marketing. Si se mantiene en el checkout, el contenedor tiene que estar restringido a etiquetas aprobadas, con control de quién puede publicar y con las publicaciones registradas. Lo más seguro es simplemente no cargarlo en las páginas de pago.
¿Qué se entrega tras una auditoría del checkout?
El inventario real de scripts que se ejecutan en la página de pago con su origen, el resultado de las pruebas de manipulación de precios y de cupones con su prueba de concepto, la evaluación de la integración con la pasarela (firmas, tokens y registros), el análisis de la política de contenido y su efectividad práctica, y un plan de remediación ordenado por impacto en el negocio.