Seguridad web: las prácticas que evitan casi todos los incidentes
Casi todas las intrusiones en sitios web no son dirigidas. Son escáneres automáticos encontrando una vulnerabilidad conocida en software desactualizado, o una contraseña reutilizada en una cuenta de administración. Defenderse de los ataques corrientes cubre la gran mayoría del riesgo real.
Esta guía cubre las prácticas que evitan casi todos los incidentes, aproximadamente por efecto, y qué hacer si un sitio ya está comprometido.
Las medidas que evitan casi todos los incidentes#
Por orden de cuánto riesgo eliminan por unidad de esfuerzo.
- Mantenga el software al día. La abrumadora mayoría de las intrusiones explotan una vulnerabilidad con parche disponible. Este único punto pesa más que todo lo que viene debajo.
- Contraseñas únicas y fuertes más doble factor en cada cuenta de administración, panel de alojamiento, registrador de dominio y cuenta de correo.
- Mínimo privilegio. Quien edita no necesita cuenta de administrador. Elimine cuentas cuando la gente se va.
- HTTPS en todas partes, con HSTS una vez esté seguro de que todos los subrecursos están disponibles por TLS.
- Copias de seguridad probadas, guardadas fuera del servidor. Una copia en la máquina comprometida se cifra junto con todo lo demás.
- Restrinja el área de administración por IP donde sea práctico, y limite siempre los intentos de acceso.
- Elimine lo que no use. Cada plugin inactivo, tema y instalación vieja es superficie de ataque sin beneficio.
Las instalaciones viejas y olvidadas —una copia de pruebas en /antiguo, un blog de prueba en una subcarpeta— son una vía de entrada habitual precisamente porque nadie las actualiza.
Entrada, salida y las vulnerabilidades clásicas#
Son responsabilidades del desarrollo y explican casi todas las vulnerabilidades que no son «no actualizó».
| Vulnerabilidad | Qué hace | Prevención |
|---|---|---|
| Inyección SQL | Lee o destruye su base de datos | Consultas parametrizadas, siempre; nunca concatenación de cadenas |
| Cross-site scripting | Ejecuta script del atacante en la sesión de un visitante | Escapar en la salida según el contexto; una Content-Security-Policy estricta |
| Cross-site request forgery | Ejecuta acciones como un usuario autenticado | Tokens por sesión en cada petición que cambia estado |
| Abuso de subida de archivos | Sube y ejecuta código | Validar el tipo por contenido, guardar fuera de la raíz web, nunca ejecutar |
| Control de acceso roto | Los usuarios alcanzan datos que no son suyos | Comprobar autorización en servidor en cada petición, no en la interfaz |
| Exposición de datos sensibles | Filtra claves y credenciales | Variables de entorno, nunca en el repositorio |
| Server-side request forgery | Hace que su servidor llame a sistemas internos | Lista de permitidos para destinos salientes |
Configuración y cabeceras#
Medidas baratas que cierran categorías enteras de problema, y casi todas se aplican en minutos.
- Sirva cabeceras de seguridad: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Desactive el listado de directorios; asegúrese de que /.git, /.env y los archivos de copia no son accesibles por HTTP.
- Desactive la salida detallada de errores en producción: las trazas son reconocimiento para el atacante.
- Bloquee el acceso a rutas de administración y configuración desde internet público donde pueda.
- Establezca las cookies con HttpOnly, Secure y un valor SameSite adecuado.
- Mantenga auditadas las dependencias; una librería vulnerable en su compilación es su vulnerabilidad.
- Registre los eventos de autenticación y alerte ante patrones inusuales.
Si el sitio ya está comprometido#
Aquí el orden importa. Limpiar archivos antes de rotar credenciales significa que el atacante simplemente vuelve por la misma puerta.
- Ponga el sitio fuera de línea o en modo mantenimiento. No lo deje sirviendo malware a los visitantes.
- Preserve pruebas: copie los registros y una instantánea de los archivos antes de cambiar nada.
- Rote todas las credenciales: alojamiento, base de datos, usuarios de administración, claves de API, correo. Dé por hecho que todas se conocen.
- Restaure desde una copia anterior a la intrusión, si puede identificar una con fiabilidad.
- Si no puede, reconstruya desde el código fuente e importe solo datos, nunca archivos de origen desconocido.
- Parchee la vulnerabilidad que les dejó entrar. Sin este paso repetirá todo el proceso.
- Busque persistencia: tareas programadas, usuarios de administración extra, archivos del núcleo modificados, contenido inyectado.
- Solicite una revisión en Search Console si el sitio fue marcado, y busque páginas de spam inyectadas.
- Notifique a los usuarios afectados si se expusieron datos personales, en muchas jurisdicciones dentro de un plazo legal.
Restaurar una copia sin cerrar la vía de entrada es el motivo más común de que un sitio se vea comprometido dos veces en quince días.
Preguntas frecuentes
¿Basta con un plugin de seguridad?
Ayuda en algunas cosas —limitar intentos de acceso, vigilar cambios en archivos, un cortafuegos básico— y no sustituye a las actualizaciones, las credenciales fuertes ni el mínimo privilegio. Un sitio con plugin de seguridad y dieciocho meses de actualizaciones sin aplicar no es seguro. Arregle primero lo fundamental y luego añada herramientas.
¿De verdad atacan a los sitios pequeños?
Constantemente, y no por quién es usted. Los escáneres automáticos prueban cada host alcanzable en busca de vulnerabilidades conocidas; los sitios pequeños resultan atractivos justo porque es menos probable que estén parcheados. Los sitios pequeños comprometidos se usan para spam, páginas de phishing y redirecciones, y por eso el nivel de tráfico de su sitio es irrelevante para el riesgo.
¿Dónde deben guardarse las copias de seguridad?
En un lugar donde el servidor web no pueda escribir, idealmente con otro proveedor, y con al menos una copia que no puedan borrar las mismas credenciales que operan el sitio. El ransomware y los ataques destructivos apuntan específicamente a las copias accesibles desde la máquina comprometida, que es exactamente el momento en que las necesita.
¿Cuál es la medida de seguridad de mayor valor?
Aplicar las actualizaciones con prontitud. Es poco vistoso y evita más intrusiones reales que todo lo demás junto, porque los ataques que de verdad ocurren son explotación automatizada de vulnerabilidades conocidas y ya parcheadas. En segundo lugar, el doble factor en las cuentas de administración y de alojamiento.
seguridad webweb hackeadabuenas prácticas seguridadinyección sqlxsscopias de seguridad web
