Hablamos
Seguridad · Tienda online
Un pago idéntico al de Redsys. Las tarjetas acababan en otro sitio.
Una tienda WooCommerce llegó para una optimización. Al revisar el checkout encontré una copia de la pasarela que se quedaba con las tarjetas antes de mandar al comprador al banco. Lo encontré porque reviso lo que nadie mira.
- Cliente
- Tienda online
- Plataforma
- WooCommerce + Redsys
- Trabajo
- Optimización y seguridad
- Amenaza
- Formjacking
Una tienda bonita. Un encargo de rutina.
La web la había hecho un freelance contratado en una plataforma externa: WordPress, WooCommerce y Redsys para cobrar. Visualmente, el trabajo era bueno.
El encargo era la optimización completa que hago a cada web que entra. Paso a paso y sin saltarme ninguno, tampoco el que casi todo el mundo se salta.
- CorreoLos correos de pedido salen y llegan, sin acabar en spam Revisado
- SeguridadVersiones, usuarios, permisos y rastro de hackeos Revisado
- ImágenesFormatos modernos y al tamaño que se muestran Optimizado
- WPOCaché, CSS y JavaScript, Core Web Vitals Optimizado
- CheckoutCampos, pasos y paso a la pasarela de pago Aquí estaba
El checkout, el gran olvidado.
Mucha gente se obsesiona con un SEO perfecto y una web que vuele. Y luego el checkout es un desastre.
El de WooCommerce de serie ha mejorado bastante con los bloques, pero un checkout mal planteado sigue siendo uno de los puntos por donde más ventas se pierden. Es la página que más dinero mueve, y casi ningún freelance la toca.
Yo sí. Y esta vez, al abrirlo, había ficheros que no pintaban nada ahí.
Lo que encontré dentro del checkout.
Código que imitaba la pantalla de pago de Redsys, servido desde la propia tienda. Tiene nombre: skimming o formjacking.
El pago se completaba en Redsys como siempre. Por eso ni el comprador ni la tienda notaban nada.
-
El comprador pulsa «Pagar»
En lugar de ir a Redsys, ve una copia exacta de su pantalla, con el logo y los colores del banco.
Mismo diseño · Servida desde el dominio de la tienda
-
Escribe su tarjeta
Número, caducidad y CVV. Los teclea en la copia, no en el banco.
-
La tarjeta sale de la tienda
El código la envía en segundo plano a una base de datos externa. El comprador no ve nada.
Petición POST en segundo plano a un servidor externo
-
Y después, al banco de verdad
Monta el formulario legítimo y lleva al comprador a Redsys. El pago entra, el pedido también. Todo parece normal.
POST firmado a Redsys: Ds_SignatureVersion, Ds_MerchantParameters y Ds_Signature (HMAC SHA-256)
Qué hice. Por este orden.
-
Cortar el robo
Lo primero, que no saliera ni una tarjeta más. Fuera los ficheros y el código que montaban la pantalla falsa.
-
Revisar la instalación entera
Si alguien deja una trampa, puede dejar dos. Repasé el núcleo, los plugins, el tema, las subidas y la base de datos, fichero a fichero.
-
Ni una puerta trasera
Busqué backdoors: usuarios ocultos, tareas programadas y código que permitiera volver a entrar cuando quisieran.
-
Un checkout bien hecho
Pasarela oficial de Redsys: la tarjeta solo se escribe en la web del banco. Y un checkout optimizado, que era el encargo.
Lo que enseña un caso así.
- Una web bonita no es una web segura. Lo que no se ve también hay que revisarlo.
- El checkout es la página que más dinero mueve. Merece la misma atención que la portada.
- Si no sabes quién ha tocado tu web, revisa qué ha dejado dentro.
¿No sabes qué hay dentro de tu web? Lo miramos.
Reviso la instalación entera y te digo qué hay. Con precio cerrado y por escrito.