Nivel de seguridad de los sitios web: lo que mostraron 884 comprobaciones de Smart Audit

Que un sitio web se abra no significa que esté protegido. El propietario ve la página principal, el formulario de pedido y el catálogo, y concluye que todo está en orden. Pero una parte de lo que ocurre con un sitio solo se ve desde fuera, con los ojos de alguien que lo examina.

Hemos puesto en marcha el servicio Smart Audit, que mira los sitios ajenos precisamente así: de forma pasiva y solo las páginas públicas. No cambia nada, no prueba contraseñas y no entra en el sistema. En el momento de preparar este artículo teníamos los resultados de 884 sitios únicos de empresas; de cada uno se toma la última comprobación correcta. No hemos seleccionado casos «buenos» o «malos»: la muestra incluye tiendas online, sitios corporativos, medios de comunicación y sitios de grandes organizaciones. No citamos nombres: nos interesa el panorama general, no direcciones concretas.

A continuación, lo que vimos, qué riesgo supone para el propietario y por dónde empezar a corregirlo.

Panorama general: 22 puntos de 100

La nota global media de los 884 sitios es de 22 de 100. Por áreas: seguridad, 19; velocidad, 18; visibilidad en buscadores, 17.

• 480 sitios (54 %) obtuvieron menos de 20 puntos de 100;
• 286 (32 %), entre 20 y 39;
• 96 (11 %), entre 40 y 59;
• solo 22 sitios (2,5 %) llegaron a 60 o más.

Si nos fijamos solo en la nota de seguridad, el cuadro es este: en 466 sitios (53 %) es inferior a 10 puntos, en 652 (74 %) es inferior a 30 y solo 75 sitios (8,5 %) alcanzaron 60 o más.

Una advertencia previa para que las cifras no se malinterpreten. «22 de 100» no significa que el sitio esté protegido al 22 %, y menos aún que lo hayan hackeado. Es la distancia respecto a un conjunto básico de comprobaciones: si el sitio activa las protecciones que desde hace tiempo se consideran la norma. La mayoría de los puntos se pierden en cuestiones que se corrigen rápido y con poco coste. Por eso merece la pena detenerse en estas cifras.

Primera capa: puertas sin cerrojo

Cada página que el servidor entrega al navegador va acompañada de «instrucciones» de servicio: qué se permite hacer a esa página y qué no. Son las llamadas cabeceras de seguridad. No hacen que un sitio sea impenetrable, pero amortiguan el golpe cuando aparece otro agujero. Y aquí la carencia es casi total:

• La política de seguridad de contenido (CSP) no existe en el 90 % de los sitios. Define qué scripts puede ejecutar el navegador en la página. Sin ella, cualquier código inyectado funciona al mismo nivel que el «propio». Así es como aparecen en las páginas de finalización de compra los skimmers: scripts que copian sin que nadie lo note los datos de las tarjetas bancarias. Para una tienda (y en la muestra hay 130) es el «cerrojo» ausente más caro.
• La política de permisos (Permissions-Policy) falta en el 93 %. Limita lo que los widgets incrustados en el sitio pueden pedir al visitante: cámara, micrófono, geolocalización.
• La política de transmisión de la dirección (Referrer-Policy) falta en el 88 %. Sin ella, las direcciones completas de sus páginas, con números internos de pedido o tokens en los enlaces, viajan a contadores y servicios publicitarios de terceros.
• La protección contra la inserción en marcos ajenos falta en el 73 %. Un atacante puede mostrar su sitio en un marco transparente dentro de su página y hacer que una persona pulse un «botón» que en realidad está en su sitio. Esta técnica se llama clickjacking.
• La prohibición de «adivinar» el tipo de archivo falta en el 71 % (nosniff).
• HSTS no está activado en el 62 %. Sin él, la primera visita de una persona puede hacerse por un canal sin cifrar, y en una red Wi-Fi pública eso abre la puerta a que se suplante la página.

Seamos honestos: la ausencia de una cabecera no significa que el sitio esté hackeado. Significa que falta un nivel de protección. Pero se corrige con unas pocas líneas en la configuración del servidor, así que su ausencia casi siempre dice una sola cosa: nadie llegó a ocuparse de los ajustes de seguridad.

Segunda capa: lo que está a la vista de todos

Este apartado es más serio. En 172 sitios de 884 (19 %), casi uno de cada cinco, hay direcciones de servicio accesibles desde fuera que nunca debieron ser públicas. Algunos sitios tienen varias de estas a la vez. Distribución por tipos:

• Listado de cuentas de WordPress: 103 sitios (12 %). La dirección estándar entrega los nombres de usuario, incluidos los de los administradores. La mitad del trabajo del atacante ya está hecha: el nombre de usuario se conoce y solo queda adivinar la contraseña.
• Carpeta de servicio de Git: 45 sitios (5 %). Permite reconstruir el código fuente del sitio, y en el historial de cambios a veces hay contraseñas y claves que alguien escribió «provisionalmente» en el código.
• Página phpinfo: 43 sitios (5 %). Muestra las versiones de PHP, los módulos, las rutas en el servidor y las variables de entorno. Para el atacante es un mapa del terreno ya preparado.
• Página de servicio con el estado del servidor: 34 sitios (4 %). Se ve qué direcciones están abriendo los visitantes en ese momento y desde qué IP.
• Archivo de configuración .env: 33 sitios (4 %). En un archivo así suelen estar las contraseñas de la base de datos y las claves del correo y de los servicios de pago.
• Copia de la base de datos: 28 sitios (3 %). Un archivo que alguien dejó en la raíz del sitio «solo un momento»: clientes, pedidos, teléfonos, direcciones.

Es importante entender que aquí no hace falta hackear nada. Basta con abrir la dirección en el navegador. Smart Audit no accede al contenido de estos archivos: solo registra que algo responde en esa dirección, y el contenido ni se lee ni se guarda. Pero lo que no hacemos nosotros lo puede hacer cualquier otro, y los escáneres automáticos recorren esas direcciones sin descanso por todo internet.

Tercera capa: software desactualizado

Entre los sitios analizados, la mayoría usa WordPress, 222 (25 %), seguido de OpenCart, 88 (10 %). En el resto no se pudo determinar la plataforma o el sitio está desarrollado «a medida».

154 sitios (17 %) revelan por sí mismos qué versión del sistema usan. Se ve en las etiquetas de servicio de la página. Por sí solas no hacen daño; el daño viene de combinarlas con una versión antigua. Entre los que muestran la versión de WordPress, 22 sitios funcionan con las ramas 4 y 5, publicadas hace muchos años. En esas versiones no conviene esperar que alguien cierre las nuevas vulnerabilidades.

Otro asunto es la versión del propio servidor. En 247 sitios (28 %), las cabeceras de respuesta indican las versiones exactas del software del servidor. El atacante no tiene que adivinar: ve la versión y aplica de inmediato el método conocido para ella. Hasta qué punto es importante lo muestra el ejemplo de las vulnerabilidades críticas de PHP: ahí la única defensa es actualizar a tiempo. Y sobre la otra cara de la moneda, lo que ocurre cuando la actualización se hace sin preparación, hablamos en el análisis de la actualización automática de un plugin.

Cuarta capa: formularios y conexiones, por donde los datos de los clientes llegan al sitio

Es a través de los formularios como una persona le facilita su nombre, teléfono, dirección y, a veces, el pago. Por eso su diseño es lo que más importa. Esto es lo que encontramos:

• 489 sitios (55 %): formularios sin protección contra la falsificación de peticiones (CSRF). Es cuando una página ajena puede hacer que el navegador de su visitante o de su administrador envíe un formulario en su nombre, sin preguntarle.
• 543 (61 %): formularios que recogen datos personales sin consentimiento para su tratamiento. No es solo una cuestión de seguridad: también lo es de cumplimiento de la legislación sobre datos personales.
• 532 (60 %): formularios sin protección contra bots. La consecuencia la conoce cualquiera que haya visto un buzón de correo saturado de «solicitudes» de spam.
• 76 sitios (9 %): formularios que transmiten datos personales en la dirección de la página (método GET). El teléfono y el nombre quedan en el historial del navegador, en los registros del servidor y llegan a servicios de terceros junto con la dirección.
• 321 (36 %): cookie sin etiquetas de protección. Es más fácil interceptarlas o leerlas con un script.

Y algunas cuestiones básicas que, en principio, deberían estar resueltas en todas partes: 35 sitios (4 %) se abren sin ningún cifrado (el navegador muestra en ellos la advertencia «No seguro»), en 43 el certificado caduca en breve y en 36 sitios parte del contenido de una página protegida se carga por un canal sin proteger, por lo que el cifrado no es completo.

Qué riesgos supone para el propietario

Dejando a un lado la jerga, los riesgos para el negocio son pocos.

1. Fuga de datos de clientes. Una copia de la base de datos o un archivo de configuración abiertos no son «un detalle técnico», sino la posibilidad de llevarse la lista de sus clientes sin haber hackeado nada. Después vienen el daño a la reputación y la responsabilidad por la custodia de los datos personales.
2. Código ajeno en su sitio. Actualizaciones que no se llegaron a instalar, más la ausencia de CSP, y en las páginas aparece publicidad de casinos, redirecciones a sitios de terceros o un skimmer en la página de pago. Puede enterarse por un cliente y no por usted mismo.
3. Etiqueta de «sitio peligroso» y caída en los buscadores. Los navegadores y los buscadores no arriesgan a sus visitantes. Un sitio hackeado puede caer en los resultados durante semanas, y recuperar la posición llevará más tiempo del que tardó en perderla.
4. Paralización y coste de la recuperación. Recuperarse tras un hackeo suele costar muchas veces más que la prevención. Y mientras el sitio está caído, no hay pedidos.
5. Pérdida de confianza de los socios. Cada vez con más frecuencia, los grandes clientes y las licitaciones piden que se demuestre cómo se gestiona la seguridad. Responder «no lo sabemos» no suma puntos.

Por dónde empezar: un orden que funciona

1. Cerrar los archivos de servicio abiertos. Son los agujeros más caros y los que más rápido se corrigen: normalmente basta con una hora de trabajo. Los archivos con contraseñas hay que retirarlos del acceso público y, después, cambiar las propias contraseñas, porque no se puede dar por hecho que no se hayan filtrado.
2. Actualizar el sistema y los plugins y eliminar de las respuestas del servidor las versiones exactas. Actualice en una copia del sitio, no a ciegas en el que está en producción.
3. Añadir cabeceras de seguridad. Empiece por HSTS, la protección contra la inserción en marcos, nosniff y Referrer-Policy: casi nunca rompen nada. La CSP debe introducirse de forma gradual, primero en modo de observación.
4. Poner en orden HTTPS: renovación automática del certificado, redirección desde http y ausencia de contenido sin proteger.
5. Revisar los formularios: token contra la falsificación de peticiones, protección contra bots, envío solo por el método POST y un consentimiento claro para el tratamiento de datos.
6. Configurar copias de seguridad fuera del sitio y monitorización. Una copia que está junto al sitio desaparece con él si hay un hackeo. Y la disponibilidad del sitio no debería comprobarla el cliente.

Cómo ayudamos

Smart Audit responde a la pregunta «qué es exactamente lo que falla» en el lenguaje de las prioridades: el informe separa los hallazgos en los que se ven de inmediato y los que están integrados en la propia plataforma del sitio. Los primeros los cerramos en su sitio actual. Los segundos (versiones antiguas, limitaciones del sistema, imposibilidad de configurar bien la protección) suelen resolverse migrando a nuestro sistema Smart CMS, donde las cabeceras de seguridad, la protección de formularios y las actualizaciones ya están integradas en su base. La migración la realizamos nosotros: trasladamos las páginas y las direcciones, conservamos los ajustes de visibilidad en buscadores y le ayudamos en cada etapa para que no pierda ni tráfico ni pedidos.

Elija por donde elija empezar, primero conviene ver su propio panorama.

---

Puede comprobar su sitio gratis, sin registro y en tres minutos, en audit.sgt.com.ua. Y si quiere que revisemos el resultado con usted y le digamos sin rodeos qué corregir primero, escríbanos.