Auditoría de seguridad de una tienda PrestaShop: qué revisar y en qué orden

Hay dos momentos para auditar una tienda: cuando sospechas que algo va mal y cuando todo parece ir bien. El primero es urgente; el segundo es el que evita el primero. En los dos casos la lista es la misma, y el orden importa: primero lo que permite entrar y quedarse, después lo que permite cobrar, y al final lo que permite recuperarse.

Esto no es una lista de buenas prácticas de configuración, sino de comprobaciones concretas: qué abrir, qué buscar y qué significa lo que encuentres.

Antes de empezar: no destruyas pruebas

Si la auditoría es por sospecha, haz primero una copia completa de ficheros y base de datos tal como están, y trabaja sobre ella siempre que puedas. Si hay una infección, necesitarás saber desde cuándo y qué tocó, y eso se pierde al limpiar.

Otra regla: no des nada por bueno mientras revisas. Si tu herramienta de vigilancia crea una línea base de «estado normal», no la crees hasta haber terminado. Una línea base hecha sobre una tienda comprometida da la infección por buena para siempre.

1. Empleados

• Lista todos los empleados y sus perfiles. ¿Reconoces a todos los superadministradores?
• Busca cuentas con identificadores consecutivos al final de la lista, correos ajenos o nombres vacíos: es el rastro típico de una inyección SQL.
• Revisa las cuentas de personas que ya no trabajan contigo, de agencias antiguas y de pruebas. Una cuenta inactiva olvidada es una puerta.
• Comprueba que todos los que deben tienen el doble factor activado.

2. Cuentas de webservice

Es la puerta de la que nadie se acuerda. Revisa en Parámetros avanzados → Webservice:

• Cuántas claves hay, para qué sirve cada una y si alguna no tiene descripción.
• Qué permisos tienen. Escritura sobre la configuración o cualquier permiso sobre empleados es mucho poder.
• Si el webservice está activo sin HTTPS forzado, la clave viaja en claro.

No desactives una clave «por si acaso» sin saber qué es: suele ser la integración del ERP o de un marketplace.

3. Módulos

• Lista los módulos instalados con su versión y compárala con la última publicada por su autor.
• Busca los que tienen avisos de seguridad publicados y los abandonados.
• Busca carpetas en modules/ sin módulo registrado: los huérfanos.
• Desconfía de los módulos sin autor reconocible, con compatibilidades imposibles o con descripciones que no explican nada.
• Revisa override/: cada fichero ahí modifica el núcleo.

4. Ficheros cambiados

La comprobación más valiosa no depende de reconocer ningún patrón:

• Compara el núcleo con el ZIP oficial de tu versión exacta, incluida vendor/. Un fichero del núcleo no debería cambiar nunca salvo por una actualización.
• Compara cada módulo con su paquete original. Lo que no estaba en el paquete lo puso alguien.
• Busca PHP donde no debe haberlo: upload/, download/, img/, imágenes con código dentro.
• Busca ficheros JavaScript con líneas desproporcionadas pegadas al principio o al final.
• Desconfía de las fechas, que se pueden falsear. Lo que cuenta es el contenido.

5. Plantillas y configuración de pago

Es donde el atacante cobra, así que merece su propio punto:

• Revisa las plantillas del checkout de todos los temas instalados, no solo el activo, buscando etiquetas <script> que no reconozcas.
• Comprueba los datos de cada método de pago: el IBAN de la transferencia, las claves de las pasarelas, las cuentas de PayPal.
• Revisa los módulos que permiten insertar HTML o código en la cabecera o el pie.
• Compara los pedidos pagados de las últimas semanas con lo que ha llegado al banco o a la pasarela.

6. Configuración de la tienda

• Las URLs de la tienda (dominio y rutas): un cambio aquí redirige el tráfico.
• La configuración del correo saliente: un SMTP cambiado permite leer o desviar los correos.
• El modo depuración desactivado en producción y la carpeta install/ borrada.
• La carpeta del back-office con un nombre que no sea el de por defecto.

7. Tareas programadas

Un cron malicioso vive fuera del árbol web, así que ningún escaneo de ficheros lo ve. Revisa las tareas del panel del hosting y, si tienes acceso, el crontab de la cuenta. Una línea que descarga algo y lo pasa a una shell, que decodifica base64 o que ejecuta PHP en línea no tiene uso legítimo. Revisa también las claves SSH autorizadas de la cuenta.

8. .htaccess y permisos

• El .htaccess de la raíz: busca redirecciones condicionadas al navegador o a la procedencia, que solo afectan a móviles o a quien llega desde un buscador.
• Los .htaccess de upload/, img/, download/ y var/: que existan y que bloqueen de verdad la ejecución.
• En PrestaShop 8 y anteriores, si modules/ permite ejecutar .php por URL.
• Que no haya carpetas con permisos de escritura para todos ni ficheros de configuración legibles por cualquiera.

9. Registros

• Registros de acceso del servidor web: peticiones POST a ficheros de módulos que no conoces, o muchas peticiones a un mismo controlador justo antes de un cambio.
• Registros de FTP y del panel del hosting, que son independientes de los web.
• Registros de errores de PHP y de PrestaShop: un error nuevo en un fichero que no ha cambiado de versión es una pista.
• Comprueba que ningún registro es accesible por URL desde fuera.

10. Copias de seguridad

• ¿Existen, son diarias y están fuera del servidor?
• ¿Se han restaurado alguna vez para comprobar que funcionan?
• ¿Hay copias antiguas sueltas en la raíz de la web, descargables por cualquiera?
• ¿Hasta cuándo llegan? Si la infección tiene meses, necesitas una copia anterior.

Y al terminar

Con todo revisado y limpio, ahora sí: crea la línea base de integridad, cambia las credenciales y deja la vigilancia funcionando. Y apunta lo que haya salido sobre las versiones: si la tienda está en un PrestaShop o un PHP sin soporte, o con módulos que no se pueden actualizar, la próxima auditoría encontrará lo mismo. Mantener la tienda al día es lo que hace que la siguiente revisión sea corta.

Cómo resolverlo en PrestaShop

RKR Security Alert automatiza buena parte de esta lista: vigila empleados, módulos, configuración (con los cambios de pago marcados como críticos), URLs de la tienda y cuentas de webservice; compara el núcleo con el ZIP oficial; escanea los ficheros en busca de puertas traseras, web shells y skimmers; controla el hash de las plantillas de checkout de todos los temas; revisa las tareas programadas y el blindaje de carpetas, y hace 14 comprobaciones de configuración del servidor. Se instala en modo primera auditoría, sin línea base hasta que das por revisado el informe. RKR Sentinel añade la vigilancia de errores y de pagos que no acaban en pedido. Y si quieres la auditoría hecha por personas, con un bono de horas de soporte de Rekire la hacemos nosotros, limpiamos lo que aparezca y te entregamos lo que queda pendiente.