Las palabras que usamos cuando hablamos de la seguridad de su tienda, explicadas sin jerga. Cada término tiene su ancla: las demás páginas del sitio enlazan directamente aquí.
Un error en un código que permite hacerle hacer lo que no debería.
Una vulnerabilidad no es un virus: es un defecto de diseño o de programación, casi siempre una comprobación olvidada sobre un dato recibido del exterior. Mientras nadie la utilice, no hace nada. El peligro aparece cuando alguien escribe la forma de aprovecharla: eso es el exploit. En PrestaShop, la inmensa mayoría de los fallos explotados no están en el núcleo sino en los módulos de terceros.
El modo de empleo que convierte un fallo en una intrusión real.
El fragmento de código o la secuencia de peticiones que aprovecha concretamente una vulnerabilidad. Es lo que hace pasar un problema teórico a un problema que le cuesta dinero: un fallo sin exploit conocido permanece latente, un fallo con exploit público es barrido por robots en pocas horas. Por eso importa tanto el plazo entre la publicación de un fallo y la actualización de su tienda.
Un fallo ya explotado cuando todavía no existe ninguna corrección.
El caso más incómodo: los ataques han empezado y el editor del módulo aún no ha publicado una actualización, y a veces no la publicará nunca, sobre todo en un módulo abandonado. Actualizar no sirve de nada porque no hay nada que instalar. Es exactamente lo que cubre un cortafuegos de aplicación: rechaza la petición de ataque antes de que llegue, lo que protege de inmediato, sin esperar una corrección que no existe.
Un acceso oculto que el atacante deja para volver cuando quiera.
Un archivo discreto depositado en su servidor, a menudo en una carpeta corriente como /upload, /img o /cache, que permite al atacante recuperar el control de la tienda incluso después de que usted haya cambiado todas sus contraseñas. Por eso «he cambiado la contraseña de administrador» nunca basta para resolver un hackeo: mientras la puerta trasera siga ahí, sigue abierta. Una limpieza seria empieza por encontrarlas todas.
Una puerta trasera manejable desde un navegador, como un panel de administración pirata.
Una forma de puerta trasera que ofrece al atacante una interfaz completa: recorrer sus archivos, subir otros, ejecutar comandos en el servidor, conectarse a su base de datos. Los webshells suelen disfrazarse: un nombre que se parece a un archivo de PrestaShop, o código escondido al final de una imagen.
Código inyectado en la página de pago que copia los números de tarjeta de sus clientes.
Unas pocas líneas de JavaScript añadidas a su proceso de compra. El cliente paga con normalidad, el pedido se registra con normalidad, y en paralelo su número de tarjeta se envía al atacante. Nada se ve a simple vista, ni para usted ni para el comprador: normalmente es el banco o un cliente quien le avisa, semanas después. Es el tipo de infección más costoso: más allá del fraude, compromete su responsabilidad RGPD.
Término genérico para todo código colocado en su sitio sin su consentimiento.
La palabra cubre tanto una puerta trasera como un script de redirección, un minero de criptomonedas o un relé de spam. En PrestaShop llega casi siempre por el mismo camino: un módulo de terceros cuya vulnerabilidad nunca se corrigió.
Sus archivos o su base de datos vueltos ilegibles, y un rescate exigido para recuperarlos.
En una tienda, el ataque rara vez adopta la forma del cifrado espectacular que se ve en los ordenadores de escritorio: lo habitual es que el atacante cifre o borre la base de datos y los archivos, y deje una nota exigiendo un pago. La única defensa que funciona de verdad es una copia de seguridad externalizada que usted ya haya probado restaurando — no una copia alojada en el mismo servidor, porque se cifra junto con todo lo demás. Pagar no garantiza nada y financia el siguiente ataque.
Manipular un formulario o una URL para hacer hablar a su base de datos.
El atacante desliza un fragmento de consulta en un campo de búsqueda, un filtro o un parámetro de URL. Si el módulo no comprueba correctamente lo que recibe, la base de datos lo ejecuta: cuentas de clientes, pedidos, a veces la creación de una cuenta de administrador. Es la vulnerabilidad más extendida en los módulos PrestaShop de terceros.
Ejecutar el código del atacante en el navegador de sus visitantes.
El atacante coloca un script en una zona que su tienda vuelve a mostrar tal cual: una reseña de producto, un nombre, un parámetro de URL. El script se ejecuta después en cada visitante que abre la página: robo de sesión, redirección o colocación de un skimmer en la página de pago.
Probar miles de contraseñas hasta dar con la correcta.
Robots prueban en bucle combinaciones de usuario y contraseña en su página de acceso de administrador. Sin limitación, una contraseña débil cae en unas horas. Más allá del riesgo de intrusión, estas oleadas ralentizan el servidor y a veces tumban la tienda por sí solas.
Un mensaje falso que le hace escribir sus credenciales en una página que imita la real.
Un correo o un SMS que se hace pasar por su alojamiento, por PrestaShop, por su proveedor de pago — o por su propio back-office — y le invita a «volver a conectarse». La contraseña escrita va directa al atacante, que después entra por la puerta principal: no hace falta ninguna vulnerabilidad técnica, y por eso un cortafuegos por sí solo no basta. Ese es el sentido del control de conexiones desde una dirección inhabitual. A tener en cuenta: los atacantes también suplantan a sus clientes, usando los datos robados de una tienda comprometida para que el mensaje resulte creíble.
Hacer que el sitio lea un archivo que nunca debería haber abierto.
Manipulando un parámetro que designa un archivo, el atacante sube por el árbol del servidor y muestra un archivo sensible, normalmente su parameters.php, que contiene las credenciales de la base de datos. En los peores casos, la vulnerabilidad permite además ejecutar un archivo subido previamente.
Mostrarle a usted una página limpia y al resto una página hackeada.
El código malicioso comprueba quién pide la página. Un visitante que llega desde Google es redirigido a spam o phishing; usted, conectado desde su dirección habitual, no ve nada anormal. Así es como un hackeo puede durar semanas sin que el comerciante se dé cuenta, hasta que el tráfico se desploma.
Su página de inicio sustituida por un mensaje del atacante.
La forma más visible de un pirateo: la tienda desaparece tras una página reivindicada por un grupo. Paradójicamente es la menos grave, porque se ve de inmediato y por tanto se trata rápido. Las infecciones que salen caras son las que se cuidan de no cambiar nada en el aspecto del sitio. Aun así es una señal seria: si alguien ha podido reescribir su página de inicio, ha tenido acceso a todo lo demás.
Su servidor secuestrado para enviar correos en nombre del atacante.
Un script alojado en el sitio envía miles de correos fraudulentos desde su servidor. Consecuencias inmediatas: su dominio queda en listas negras de los proveedores de correo (sus confirmaciones de pedido reales dejan de llegar) y su alojamiento acaba suspendiendo la cuenta.
Nadie le ha elegido: hay robots llamando a todas las puertas, sin parar.
«¿Por qué mi tienda? No soy Amazon.» Porque ningún humano le ha apuntado. Redes de máquinas comprometidas recorren Internet de forma continua y prueban en cada sitio la lista de fallos publicados, sin distinguir tamaño ni facturación. Una tienda pequeña con un módulo sin actualizar es un objetivo tan válido como una grande, y a menudo más, porque está menos vigilada. Es también lo que hace eficaz la lista negra compartida: son las mismas direcciones las que llaman en todas partes.
Un filtro que bloquea las peticiones hostiles antes de que lleguen a su tienda.
Donde un antivirus mira sus archivos, el cortafuegos de aplicación mira el tráfico entrante y rechaza lo que se parece a un ataque: inyección SQL, script inyectado, intentos masivos de acceso. Su valor principal es el tiempo: protege una vulnerabilidad conocida de inmediato, sin esperar a que el editor del módulo publique una corrección.
El identificador público de una vulnerabilidad conocida.
Cuando se descubre una vulnerabilidad en PrestaShop o en un módulo, recibe un número de referencia mundial, por ejemplo CVE-2024-6648. Ese número es público: los atacantes lo usan como catálogo y rastrean internet buscando tiendas que aún no se han actualizado. Es una carrera entre el momento en que se publica la vulnerabilidad y el momento en que usted la corrige.
La ficha que describe una vulnerabilidad: módulo afectado, versiones, corrección.
Para cada vulnerabilidad que seguimos mantenemos una ficha: qué módulo, qué versiones son vulnerables, a partir de qué versión está corregida y qué hacemos mientras tanto. Su panel cruza esas fichas con los módulos realmente instalados en su tienda, para mostrarle solo lo que le concierne.
Comparar cada uno de sus archivos con el original oficial de PrestaShop.
Cada archivo tiene una huella digital única. Al comparar la huella de sus archivos con la de los archivos oficiales de su versión de PrestaShop, detectamos con precisión qué se ha modificado, añadido o eliminado, incluso cuando el código inyectado está demasiado bien escrito para parecer un virus.
Un ataque bloqueado en un cliente protege de inmediato a todos los demás.
Cuando una dirección IP ataca una tienda de la red, se añade a una lista compartida por todas las tiendas protegidas. El mismo atacante que se presente después en su sitio es rechazado antes incluso de intentarlo. Cuantas más tiendas hay en la red, más actualizada está la lista.
Un segundo factor además de la contraseña, para que una contraseña robada ya no baste.
Un código de un solo uso solicitado además de la contraseña en el momento de conectarse. Es la única protección realmente eficaz contra el phishing y el robo de credenciales: incluso con la contraseña correcta, el atacante queda detenido. El mismo principio se aplica al control de las conexiones de administrador desde una dirección que la tienda nunca ha utilizado: se exige una prueba adicional antes de dejar entrar.
Un archivo señalado como sospechoso cuando es perfectamente legítimo.
Algunos módulos comerciales incluyen código comprimido o codificado que, de lejos, se parece a código malicioso. Un buen antivirus debe señalarlo en lugar de ignorarlo, pero también debe permitir zanjar la cuestión rápido. El panel le da el contexto y el extracto exacto de código para decidir, y nuestro equipo arbitra los casos dudosos.
Cerrar las puertas innecesarias para reducir lo que un atacante puede alcanzar.
El conjunto de ajustes que hacen una intrusión más difícil y menos rentable: permisos de archivos correctos, versión de PHP mantenida, acceso de administrador restringido, carpetas de instalación eliminadas. No es una protección contra un ataque concreto: es lo que hace que una vulnerabilidad explotada cause menos daño.
La pantalla roja «Sitio peligroso» que corta su tráfico.
Cuando Google detecta contenido malicioso en una tienda, muestra un aviso a pantalla completa antes de dejar entrar al visitante, y el posicionamiento se hunde. La retirada no es automática: hay que limpiar y después solicitar una revisión en Search Console. Cuente entre 24 y 72 horas tras la validación.
Cerrar un fallo sin cambiar la versión del módulo.
Cuando se publica un fallo, la respuesta normal es actualizar el módulo — siempre que el editor haya publicado una versión corregida, que sea compatible con su tienda y que usted pueda instalarla. Un parche actúa de otra manera: modifica exactamente las líneas defectuosas en la versión que ya tiene. El fallo se cierra sin cambio de versión, sin riesgo de regresión en su plantilla, y la operación es reversible.
Avisar primero al editor, publicar el detalle después — o nunca.
Publicar el detalle de un fallo antes de que el editor lo haya corregido arma a cualquiera contra todas las tiendas que usan ese módulo. La divulgación coordinada consiste en avisar al editor, darle tiempo para publicar una corrección y publicar solo después. Por eso contamos públicamente nuestros propios descubrimientos sin nombrar nunca el módulo mientras la corrección no esté disponible para todos.
¿Falta un término o una definición no queda clara? Díganoslo y la añadimos.
