Auditoría web pasiva: alcance técnico y límites jurídicos

1. Introducción

Desde el punto de vista técnico, OWASP denomina passive testing a la fase en la cual el auditor explora la aplicación como lo haría un usuario y observa las solicitudes y respuestas HTTP. De ese modo puede estudiar encabezados, parámetros, cookies, interfaces, tecnologías y puntos de entrada.

Sin embargo, incluso la navegación ordinaria genera tráfico hacia el servidor. Por ello conviene diferenciar tres niveles: reconocimiento estrictamente pasivo, observación web de baja interacción y pruebas activas.

2. Tres niveles de análisis

2.1. Reconocimiento estrictamente pasivo

Existe reconocimiento estrictamente pasivo cuando el investigador no envía tráfico directamente al sistema examinado, sino que obtiene información de fuentes externas o previamente publicadas.

• Consulta de registros DNS mediante servicios públicos.
• Información registral del dominio mediante WHOIS o RDAP.
• Registros públicos de certificados digitales.
• Resultados de motores de búsqueda.
• Versiones archivadas de páginas públicas.
• Repositorios públicos de código.
• Documentación técnica o publicaciones institucionales.
• Bases públicas de vulnerabilidades conocidas.
• Información pública sobre alojamiento, CDN y sistemas autónomos.

Este nivel suele presentar el menor riesgo técnico y jurídico, porque no existe interacción directa con el servidor auditado. Aun así, deben respetarse la legislación sobre datos personales, propiedad intelectual, confidencialidad y uso legítimo de la información.

2.2. Observación web de baja interacción

Comprende acciones que generan solicitudes al servidor, pero reproducen una navegación ordinaria y no intentan forzar comportamientos anómalos.

• Abrir páginas públicas en un navegador.
• Realizar una solicitud HTTP GET o HEAD sobre una URL pública.
• Observar redirecciones entre HTTP y HTTPS.
• Examinar el certificado TLS presentado por el servidor.
• Leer encabezados HTTP.
• Analizar HTML, JavaScript y CSS enviados al navegador.
• Examinar robots.txt, sitemap.xml o security.txt.
• Revisar cookies creadas durante la sesión propia.
• Observar formularios públicos sin enviar datos.
• Analizar documentos públicamente enlazados y sus metadatos.

Aunque estas acciones suelen calificarse como pasivas en la práctica profesional, producen interacción. Por eso deben ejecutarse con baja frecuencia, sin automatizaciones agresivas y sin provocar una carga superior a la navegación normal.

2.3. Pruebas activas

Las pruebas activas buscan provocar una respuesta especial, descubrir recursos no visibles, confirmar una vulnerabilidad o superar una restricción.

• Escaneo de puertos o enumeración masiva de servicios.
• Búsqueda automatizada de directorios y archivos.
• Fuzzing de parámetros.
• Inyección de código, comandos o consultas SQL.
• Pruebas de cross-site scripting mediante cargas útiles.
• Intentos de autenticación, fuerza bruta o password spraying.
• Evasión de CAPTCHA o controles de acceso.
• Manipulación de tokens o sesiones.
• Acceso a copias de respaldo no enlazadas.
• Explotación de vulnerabilidades conocidas.
• Interceptación de tráfico de terceros.
• Carga de archivos o modificación de datos.
• Pruebas de denegación de servicio.

Estas actividades no deben presentarse como auditoría pasiva. Como regla profesional, requieren autorización previa, expresa, documentada y otorgada por quien tenga facultades sobre los sistemas involucrados.

3. Información que puede obtenerse mediante una auditoría pasiva

3.1. Información sobre el dominio

A partir de fuentes públicas pueden identificarse el nombre de dominio, registrador, servidores DNS, registros A, AAAA, MX, TXT y CNAME, políticas SPF y DMARC, selectores DKIM publicados, subdominios conocidos, direcciones IP, proveedor de alojamiento y sistema autónomo.

La existencia de esta información no demuestra una vulnerabilidad. Sirve para elaborar un inventario externo de activos y detectar exposiciones innecesarias, configuraciones contradictorias o dependencias de terceros.

3.2. Certificados digitales y uso de HTTPS

Una observación de baja interacción permite comprobar:

• Si el sitio utiliza HTTPS.
• Si redirige desde HTTP hacia HTTPS.
• Si el certificado está vigente.
• Si el nombre del dominio coincide con el certificado.
• La entidad emisora y la cadena de certificación.
• Los nombres alternativos incluidos.
• La existencia del encabezado HSTS.
• La presencia de contenido mixto.
• Errores visibles de validación.

La ausencia de HSTS no prueba por sí sola que el sitio haya sido vulnerado. Puede describirse como una protección faltante o una oportunidad de mejora, según la arquitectura y el contexto del sistema.

3.3. Encabezados HTTP

Los encabezados enviados por el servidor permiten conocer aspectos de configuración y seguridad, entre ellos:

• Server y X-Powered-By.
• Strict-Transport-Security.
• Content-Security-Policy.
• X-Frame-Options.
• X-Content-Type-Options.
• Referrer-Policy.
• Permissions-Policy.
• Encabezados CORS.
• Directivas de caché.
• Encabezados relacionados con cookies.

La ausencia de uno de estos encabezados debe describirse como debilidad de configuración o medida de protección no observada, y no como prueba automática de una intrusión o vulnerabilidad explotable.

3.4. Cookies de la propia sesión

El auditor puede observar las cookies que el sitio coloca en su propio navegador y comprobar su nombre, dominio, ruta, vencimiento y atributos Secure, HttpOnly y SameSite.

3.5. Código entregado al navegador

Todo navegador necesita recibir determinados recursos para representar la página. Por eso pueden examinarse HTML, CSS, JavaScript, comentarios, bibliotecas, rutas de API visibles, variables públicas, nombres de archivos, mapas de código fuente y mensajes de depuración.

Que el código sea entregado al navegador no significa que carezca de protección jurídica. La legislación uruguaya sobre derecho de autor incluye expresamente a los programas de ordenador, tanto en código fuente como en código objeto, entre las obras protegidas.

3.6. Archivos de metadatos y orientación para rastreadores

Pueden examinarse archivos públicos como robots.txt, sitemap.xml, security.txt, manifiestos de aplicaciones y políticas de seguridad.

robots.txt no constituye un mecanismo de autenticación ni vuelve privados los recursos mencionados. Sin embargo, tampoco debe interpretarse como una invitación a acceder a cada ruta allí indicada.

3.7. Documentos públicos y metadatos

Archivos PDF, documentos de texto, planillas e imágenes publicados por una organización pueden contener nombres de usuario, software utilizado, fechas de creación, rutas locales, coordenadas, historial de revisiones, comentarios, firmas electrónicas e información personal.

El análisis de estos metadatos puede integrar una auditoría pasiva cuando el documento fue publicado legítimamente. La recopilación, almacenamiento y difusión de datos personales debe cumplir la Ley N.º 18.331.

3.8. Tecnologías y componentes

A partir de encabezados, cookies, estructura HTML, nombres de archivos y patrones de respuesta pueden inferirse servidores web, lenguajes, gestores de contenido, marcos de desarrollo, bibliotecas JavaScript, CDN, plataformas de analítica y proveedores de autenticación.

Las identificaciones deben presentarse con un nivel de certeza. Es preferible expresar que «se observaron indicadores compatibles con WordPress» antes que afirmar de manera concluyente una versión exacta cuando no ha sido verificada internamente.

4. Qué no demuestra una auditoría pasiva

• No demuestra que el sitio haya sido atacado.
• No confirma por sí sola una vulnerabilidad explotable.
• No permite conocer toda la arquitectura interna.
• No verifica reglas internas de firewall, segmentación, respaldo o monitoreo.
• No autoriza a confirmar una falla mediante explotación.

El informe debe diferenciar claramente entre hecho observado, inferencia técnica, riesgo posible, vulnerabilidad confirmada y vulnerabilidad no confirmada por falta de prueba autorizada.

5. Marco penal uruguayo

5.1. Acceso ilícito a datos informáticos

El artículo 297 BIS del Código Penal, incorporado por la Ley N.º 20.327, sanciona determinadas conductas realizadas sin autorización y sin justa causa sobre información ajena contenida en soporte digital.

Esta disposición obliga a diferenciar entre observar contenido deliberadamente publicado y acceder a información no destinada al público, superar una autenticación, aprovechar un error de autorización o descargar archivos confidenciales.

5.2. Interceptación ilícita

El artículo 297 TER sanciona la interceptación, interrupción o interferencia, sin autorización y sin justa causa, de datos informáticos transmitidos de manera no pública.

Por ello una auditoría pasiva no debe incluir captura de comunicaciones de terceros, ataques de intermediario, instalación de certificados en dispositivos ajenos, captura de credenciales o lectura de tráfico interno.

5.3. Vulneración de datos

El artículo 297 QUATER contempla conductas no autorizadas sobre datos confidenciales de terceros y determinadas formas de difusión, revelación o cesión.

Si durante el análisis aparece accidentalmente información personal o confidencial, el investigador debería detener el acceso, no continuar enumerando registros, no descargar bases completas, conservar solo la evidencia mínima y comunicar el hallazgo por un canal seguro.

5.4. Daño informático

El artículo 358 QUATER del Código Penal sanciona determinadas conductas de destrucción, alteración o inutilización no autorizada de datos o sistemas informáticos.

Una auditoría pasiva correctamente diseñada no debería alterar ningún elemento ni ejecutar pruebas destructivas, bloquear cuentas, modificar registros o afectar la disponibilidad del sistema.

5.5. Herramientas de seguridad y abuso de dispositivos

El artículo 358 QUINQUIES sanciona determinadas conductas ilegítimas relacionadas con programas, sistemas, credenciales o contraseñas destinados inequívocamente a la comisión de delitos.

Herramientas como Nmap, Wireshark, Burp Suite u OWASP ZAP no son ilícitas por su mera existencia. Son herramientas de doble uso. La valoración jurídica depende de la finalidad, autorización, alcance, objetivo examinado, módulos ejecutados, información obtenida y conducta posterior.

6. Protección de datos personales

La Ley N.º 18.331 regula el tratamiento de datos personales en Uruguay. Una auditoría puede involucrar tratamiento cuando se recopilan, registran, organizan, almacenan, correlacionan o comunican datos vinculados a personas identificadas o identificables.

La procedencia pública de un dato no elimina los principios de legalidad, finalidad, proporcionalidad, seguridad, reserva y responsabilidad.

Principios prácticos para el auditor

• Minimización: recolectar únicamente lo necesario para documentar el hallazgo.
• Finalidad: no reutilizar los datos para fines incompatibles.
• Seguridad: proteger informes, capturas y archivos.
• Reserva: limitar el conocimiento a quienes deban intervenir.
• Retención limitada: eliminar datos cuando ya no sean necesarios.
• Anonimización: ocultar nombres, documentos, teléfonos, correos, tokens y credenciales.
• Protección reforzada: evitar especialmente datos de salud, menores de edad, información financiera u otros datos sensibles.

7. Privacidad y secreto de las comunicaciones

El artículo 28 de la Constitución uruguaya declara inviolables los papeles de los particulares y su correspondencia epistolar, telegráfica o de cualquier otra especie, salvo los casos establecidos legalmente.

Esta protección constitucional debe orientar la interpretación de las prácticas técnicas. Una auditoría no puede ampararse en su supuesto carácter pasivo para acceder a correos privados, mensajes internos, comunicaciones de usuarios, formularios enviados por terceros o registros de autenticación individualizados.

8. Responsabilidad civil

Además de las consecuencias penales o administrativas, una actividad de auditoría puede generar responsabilidad civil. El artículo 1319 del Código Civil establece el deber de reparar el daño causado por un hecho ilícito, doloso, culposo o negligente.

Podría existir responsabilidad si el auditor sobrecarga el servidor, interrumpe un servicio, bloquea cuentas, corrompe datos, publica una vulnerabilidad prematuramente, divulga datos personales o formula afirmaciones técnicas inexactas que afecten la reputación de la organización.

9. Términos de uso, restricciones técnicas y buena fe

Antes de iniciar el análisis deberían revisarse los términos y condiciones, aviso legal, política de privacidad, política de seguridad, programa de divulgación responsable, programa de recompensas, archivo security.txt, restricciones de automatización y reglas de uso de API.

El incumplimiento de términos de uso no equivale automáticamente a la comisión de un delito, pero puede producir consecuencias contractuales o ser considerado al evaluar la ausencia de autorización y la buena fe.

CAPTCHA, autenticación, límites de velocidad, tokens y restricciones de sesión no deben ser eludidos bajo la denominación de auditoría pasiva.

10. Semáforo técnico-jurídico

11. La autorización para auditar

Cuando la auditoría exceda la observación pública ordinaria, la autorización debería constar por escrito y provenir de quien tenga facultades sobre el sistema.

Contenido mínimo recomendado

• Identificación del titular y del auditor.
• Dominios, subdominios, IP, aplicaciones y APIs incluidas.
• Activos y proveedores expresamente excluidos.
• Métodos permitidos y técnicas prohibidas.
• Fechas, horarios y límites de solicitudes.
• Direcciones IP de origen.
• Tratamiento de datos y evidencia.
• Canal de emergencia y condiciones de interrupción.
• Obligaciones de confidencialidad.
• Procedimiento de reporte y corrección.

12. Metodología recomendada

Fase 1. Definición jurídica y técnica

Establecer finalidad, titular, base de autorización, alcance, fuentes permitidas, herramientas, límites de interacción y tratamiento de datos.

Fase 2. Recolección desde fuentes externas

Consultar DNS, RDAP o WHOIS, certificados, motores de búsqueda, repositorios públicos, documentos institucionales y bases de vulnerabilidades.

Fase 3. Navegación ordinaria controlada

Abrir la portada, comprobar HTTP y HTTPS, seguir enlaces visibles, observar redirecciones, encabezados, cookies propias, recursos entregados y formularios sin enviar información.

Fase 4. Análisis de configuración

Clasificar los resultados como configuración correcta, oportunidad de mejora, exposición de información, indicador de vulnerabilidad, vulnerabilidad potencial no confirmada o incidente crítico.

Fase 5. Validación de evidencias

Registrar fecha, hora, URL, método, solicitud, respuesta, captura, impacto posible, nivel de certeza, recomendación y limitaciones.

Fase 6. Comunicación responsable

Enviar el informe al responsable del sistema mediante un canal seguro. Cuando corresponda, considerar la comunicación a CERTuy.

13. Cómo redactar correctamente los hallazgos

Ejemplo incorrecto

«El sitio puede ser fácilmente hackeado porque no tiene HSTS».

Ejemplo correcto

«En la respuesta HTTPS observada no se recibió el encabezado Strict-Transport-Security. Esta ausencia puede aumentar el riesgo en determinados escenarios de primer acceso. No se realizaron pruebas de interceptación ni se confirmó explotación».

Ejemplo incorrecto

«El sitio utiliza una versión vulnerable de PHP».

Ejemplo correcto

«El servidor expuso un encabezado compatible con PHP versión X. La identificación se basa exclusivamente en información declarada por el servidor y podría no reflejar el estado real de los parches».

14. Precauciones jurídicas esenciales

1. Definir qué se entiende por pasivo. No incluir escaneo, fuzzing o explotación bajo esa denominación.
2. Obtener autorización cuando exista interacción especial.
3. No eludir controles.
4. No utilizar credenciales ajenas.
5. No acceder deliberadamente a información confidencial.
6. Aplicar minimización de datos.
7. Evitar impactos operativos.
8. No publicar detalles explotables prematuramente.
9. Proteger la evidencia.
10. Diferenciar hechos, inferencias y riesgos.
11. Mantener trazabilidad técnica.
12. Respetar servicios de terceros.

15. Conclusión

La auditoría web pasiva constituye una herramienta legítima y valiosa para conocer la superficie pública de exposición de un sitio, detectar configuraciones deficientes y formular recomendaciones preventivas sin ejecutar una intrusión.

No obstante, el concepto «pasivo» debe emplearse con rigor. La automatización intensiva, la enumeración forzada, el escaneo, la manipulación de parámetros, el acceso a información no destinada al público y la explotación de vulnerabilidades exceden la mera observación.

En Uruguay, el análisis debe considerar especialmente los delitos informáticos incorporados al Código Penal, la Ley N.º 18.331 sobre protección de datos personales, la inviolabilidad de las comunicaciones, la protección jurídica del software y las reglas generales de responsabilidad civil.

Observar lo que el sistema publica no equivale a tener autorización para probar todo lo que técnicamente podría hacerse sobre él.