Un análisis profundo de seguridad web combina varias comprobaciones para obtener una visión más completa del estado de un sitio. No se limita a buscar virus: también puede revisar vulnerabilidades, configuraciones, archivos, base de datos, reputación, usuarios, comportamiento de la aplicación y exposición del servidor.
Ninguna herramienta aislada puede garantizar que un sitio sea seguro. Un escáner externo observa lo que está disponible desde Internet, mientras que uno con acceso al hosting puede inspeccionar archivos y bases de datos. Una revisión útil combina ambas perspectivas y prioriza los hallazgos según su riesgo real.
Contenido de esta guía
- Qué debería incluir el análisis
- Tipos de pruebas de seguridad
- Archivos, malware y base de datos
- Vulnerabilidades y componentes
- Configuración, accesos y servidor
- Reputación y señales externas
- Cómo interpretar los resultados
- Cuándo conviene repetir el análisis
Qué debería revisar un análisis de seguridad web
El alcance depende del tipo de sitio, la tecnología utilizada y los permisos disponibles. Como mínimo conviene evaluar:
- Malware, código inyectado y archivos desconocidos.
- Versiones vulnerables del CMS, temas, plugins y bibliotecas.
- Formularios, autenticación, sesiones y permisos.
- Configuración HTTPS y certificados.
- Usuarios administrativos y credenciales expuestas.
- Base de datos, tareas programadas y mecanismos de persistencia.
- Cabeceras de seguridad y exposición de información.
- DNS, subdominios y servicios publicados.
- Reputación del dominio y advertencias externas.
- Logs, cambios recientes y actividad anómala.
Un informe que solamente enumera problemas sin explicar gravedad, evidencia y corrección tiene utilidad limitada. El resultado debería permitir decidir qué resolver primero.
Tipos de pruebas: qué ve cada una
| Tipo de análisis | Qué observa | Limitación principal |
|---|---|---|
| Escaneo externo | Páginas, respuestas HTTP, formularios, puertos y comportamiento visible desde Internet. | No ve necesariamente archivos internos o la base de datos. |
| Escaneo de archivos | Código, firmas, modificaciones y archivos sospechosos del hosting. | Necesita acceso y puede requerir revisión manual. |
| Escaneo de base de datos | Contenido inyectado, usuarios, opciones y registros maliciosos. | Debe conocer la estructura de la aplicación. |
| Análisis de vulnerabilidades | Versiones, configuraciones y fallas conocidas como XSS o inyección SQL. | Una alerta no demuestra siempre que la falla sea explotable. |
| Prueba de penetración | Validación controlada de vulnerabilidades por un especialista. | Requiere alcance, autorización y metodología definidos. |
| Monitoreo continuo | Cambios y nuevas detecciones a lo largo del tiempo. | No sustituye una investigación profunda después de un incidente. |
OWASP diferencia los escáneres automatizados de las pruebas de seguridad más amplias. La Web Security Testing Guide ofrece una metodología de referencia para evaluar aplicaciones web.
Análisis de archivos, malware y base de datos
La revisión debe buscar más que nombres conocidos. Un atacante puede modificar archivos legítimos, insertar código ofuscado o crear mecanismos que vuelvan a descargar la infección.
En los archivos conviene comprobar:
- Archivos nuevos o modificados recientemente.
- Código ofuscado, funciones peligrosas y cargas remotas.
- Puertas traseras, webshells y scripts ocultos.
- Archivos ejecutables dentro de directorios de imágenes o caché.
- Diferencias respecto de las versiones oficiales del CMS.
- Cambios en archivos de configuración y reglas de redirección.
En la base de datos conviene comprobar:
- Usuarios administrativos desconocidos.
- JavaScript, iframes o enlaces inyectados.
- Opciones que cargan código o redirecciones.
- Entradas y páginas creadas para spam SEO.
- Tareas programadas o tokens que mantengan el acceso.
La documentación de SiteLock diferencia resultados limpiados, maliciosos, sospechosos y en revisión. Una etiqueta de “sospechoso” requiere contexto y no debería llevar a borrar automáticamente un archivo legítimo.
Vulnerabilidades, versiones y aplicación
Un sitio puede estar limpio y seguir siendo vulnerable. El análisis debe revisar el CMS, extensiones, plantillas y bibliotecas, junto con la configuración que determina cómo se utilizan.
Entre los riesgos habituales se encuentran:
- Plugins o temas abandonados.
- Versiones con vulnerabilidades conocidas.
- Inyección SQL y cross-site scripting (XSS).
- Subida de archivos sin validación.
- Controles de acceso insuficientes.
- Sesiones y cookies inseguras.
- Exposición de archivos de configuración o backups.
- APIs y formularios sin protección contra abuso.
El OWASP Top 10 es una referencia para comprender los riesgos más relevantes de las aplicaciones web, pero no representa una lista exhaustiva.
Configuración, accesos y servidor
La seguridad de la aplicación depende también del entorno donde funciona. El análisis debería incluir, según el acceso disponible:
Accesos y usuarios
- Cuentas administrativas y permisos asignados.
- Contraseñas reutilizadas o credenciales antiguas.
- Autenticación de dos factores.
- Cuentas FTP, correo, base de datos y claves API.
- Sesiones activas y dispositivos autorizados.
Servidor y hosting
- Versiones de PHP, servidor web y base de datos.
- Permisos de archivos y propietarios.
- Tareas cron y procesos persistentes.
- Servicios y puertos expuestos.
- Logs de acceso, errores y autenticación.
- Backups externos y pruebas de restauración.
HTTPS y cabeceras
- Certificado válido y cadena completa.
- Redirección consistente hacia HTTPS.
- Contenido mixto y recursos inseguros.
- Cookies con atributos adecuados.
- Políticas como Content Security Policy cuando sean compatibles.
Reputación, buscadores y servicios externos
Un análisis profundo también debería buscar señales que aparecen fuera del servidor: advertencias del navegador, problemas de seguridad en Search Console, bloqueos de antivirus, reputación del dominio y actividad de correo sospechosa.
Estas señales pueden descubrir incidentes que el propietario todavía no vio. Sin embargo, cada proveedor utiliza criterios propios. Consultá nuestra guía sobre cómo interpretar una alerta de reputación web.
Cómo interpretar los resultados
No todas las alertas tienen la misma gravedad. Para priorizarlas conviene registrar:
- Activo afectado: archivo, URL, usuario, base de datos o servicio.
- Evidencia: fragmento, firma, respuesta o comportamiento observado.
- Exposición: si puede ser alcanzado desde Internet y por quién.
- Impacto: robo de datos, ejecución de código, caída o daño reputacional.
- Probabilidad: facilidad de explotación y controles existentes.
- Acción recomendada: mitigación temporal y solución definitiva.
| Prioridad orientativa | Ejemplos | Respuesta |
|---|---|---|
| Crítica | Malware activo, puerta trasera, robo de credenciales o ejecución remota. | Contener e investigar inmediatamente. |
| Alta | Vulnerabilidad explotable, administrador desconocido o spam saliente. | Corregir con urgencia y revisar alcance. |
| Media | Software desactualizado o configuración débil sin explotación confirmada. | Planificar corrección pronta. |
| Baja | Información expuesta o mejora defensiva sin impacto inmediato. | Corregir dentro del mantenimiento normal. |
Una alerta automática puede ser un falso positivo. Verificá el archivo, su origen y la evidencia antes de eliminarlo. Si el hallazgo es malware confirmado, seguí la guía específica sobre qué hacer ante una detección de malware web.
Cuándo conviene repetir el análisis
- Después de publicar o migrar un sitio.
- Antes y después de actualizaciones importantes.
- Tras instalar un plugin, tema o integración externa.
- Cuando aparece una alerta, redirección o cambio desconocido.
- Después de una limpieza para confirmar que no quedan rastros.
- Periódicamente en sitios comerciales o con datos de usuarios.
El monitoreo diario puede detectar cambios entre revisiones manuales. SiteLock combina distintos análisis según el plan contratado; conocé cómo funciona SiteLock y compará los planes Find, Fix y Defend.
Lista de verificación final
- El alcance del análisis está definido.
- Se combinaron pruebas externas e internas cuando fue posible.
- Se revisaron archivos y base de datos.
- Se comprobaron componentes y vulnerabilidades.
- Se revisaron usuarios, credenciales y tareas programadas.
- Se verificaron HTTPS, DNS y configuración del hosting.
- Cada hallazgo tiene evidencia y prioridad.
- Las correcciones se validaron con un nuevo análisis.
Preguntas frecuentes
¿Un escaneo sin alertas garantiza que el sitio está seguro?
No. Indica que la herramienta no detectó problemas dentro de su alcance. Pueden existir fallas nuevas, lógicas o accesibles únicamente con determinados permisos.
¿Un análisis de vulnerabilidades es igual a una prueba de penetración?
No. El escaneo identifica posibles problemas automáticamente. Una prueba de penetración valida fallas de forma controlada bajo un alcance y autorización definidos.
¿Debo borrar todo archivo marcado como sospechoso?
No. Primero comprobá si pertenece a la aplicación, revisá la evidencia y comparalo con una copia oficial. Un falso positivo eliminado sin análisis puede romper el sitio.
¿SiteLock reemplaza la seguridad del hosting?
No. Es una capa complementaria de análisis, remediación o protección según el plan. El hosting y la aplicación deben seguir administrándose correctamente.
