Vulnerabilidades de las pruebas de vulnerabilidades

Recientemente hemos estado involucrados en varios proyectos que han recibido reportes relacionados con escaneos de vulnerabilidades en sitios Web y aplicaciones, tendencia que se ha intensificado en los últimos meses dado el auge de la inteligencia artificial y su rol fundamental en la aceleración de las capacidades de quienes buscan comprometer la seguridad de estas soluciones.

El valor real de una prueba de vulnerabilidad

Partamos de lo teórico: los “verdaderos positivos” —hallazgos reales y válidos— son una invitación permanente a considerar nuevas amenazas, diseñar controles efectivos de mitigación y comprender mejor los patrones de ataque, así como su evolución. Encontrar oportunidades genuinas de mejora es, precisamente, el propósito principal de una prueba de vulnerabilidad. Y eso no solo es positivo: es deseable.

Sin embargo, existen también los llamados “falsos positivos”, hallazgos que, tras la debida diligencia, se determina que no aplican por alguna razón valida dentro del sitio Web o aplicación auditados. Son un subproducto algo extraño, pero natural, de un sistema que como el escáner de vulnerabilidades “no puede saberlo todo” y de un método que, aunque profesional aún tiene aún mucho por afinar para alcanzar una precisión cercana al 100%.

Este reconocimiento tácito de que las pruebas de vulnerabilidad tienen sus propias vulnerabilidades no es tan inocente como parece: genera costos, reprocesos y fricciones que afectan negativamente al proyecto auditado.

Los "positivos imposibles": cuando la realidad supera a la norma

Pero más allá de los falsos positivos —ampliamente documentados—, valdría la pena postural una tercera categoría que merece atención especial: los “positivos imposibles”. Son aquellos hallazgos que, siendo técnicamente reales, no tienen solución práctica posible. Y no por incapacidad del equipo del equipo de desarrollo o soporte, ni por descuido o negligencia, sino por una verdadera limitación técnica inherente al entorno.

Dos casos ilustran claramente este fenómeno:

“inline-unsafe” en librerías de terceros.

En los reportes se penaliza el uso del valor “unsafe-inline” dentro de las directivas de seguridad de contenido (CSP) para categorías como script o style. Aunque eliminar su utilización en la categoría script es esencial para mantener una política sólida y en consecuencia una seguridad adecuada, pero su uso dentro de la categoría style merece al menos matizarse. El motivo: muchas librerías ampliamente utilizadas —como ciertos frameworks de UI, widgets embebidos, herramientas de visualización o componentes de terceros— inyectan estilos en línea de manera interna, como parte de su funcionamiento normal. El sitio Web o aplicación que utiliza estas librerías no tiene control sobre ese comportamiento y aun cuando fuera posible por parte de los desarrolladores modificar el código fuente de tales librerías para evitar esta situación, esto no solo va en contra de las buenas prácticas e introduce riesgos de mantenimiento, sino que en muchos casos simplemente no es viable. 

Así que, aunque el hallazgo es técnicamente correcto, la solución prescrita es, en la práctica, inaplicable sin abandonar herramientas que pueden resultar esenciales para el proyecto.

Integridad de subrecursos (SRI) inaplicable a elementos mutables o fuera del control del proyecto

La política de Integridad de Subrecursos (“Subresource Integrity” o SRI) permite verificar que los archivos cargados desde fuentes externas no hayan sido alterados, mediante un hash criptográfico. Esta medida es válida y deseable para recursos inmutables o sobre los que se mantiene control sobre su desarrollo. El problema surge cuando se exige aplicar SRI a recursos que, por su naturaleza, son dinámicos o sobre los que no se tiene control alguno: un caso bien conocido es la librería de Google Analytics. Primero al ser dinámica, puede cambiar su contenido haciendo que su hash también se modifique en cada despliegue y segundo que Google no informa a través de ningún mecanismo cuál podría ser el valor de ese parámetro, haciendo imposible capturarlo para su validación efectiva.

En este caso el hallazgo existe en teoría, pero la recomendación de su remediación es técnicamente incompatible con la arquitectura misma del sistema.

Como se observa, en ocasiones la teoría choca con la realidad, y esta última siempre gana. 

El efecto multiplicador del problema

Esta vulnerabilidad de las pruebas de vulnerabilidad tiene un efecto multiplicador que amplía su perjuicio: se convierte, silenciosamente, en una fuente de gastos, reprocesos y tensiones que no benefician a nadie, y menos aún al proyecto que se pretende proteger.

Por eso, a continuación, compartimos algunas recomendaciones —respetuosas y constructivas— dirigidas a los equipos de expertos encargados de estas revisiones.

1. Conocer cada vector en profundidad práctica, no solo teórica.

Es fundamental entender qué implica realmente cada sugerencia en el contexto específico del sistema auditado. Ceñirse mecánicamente a la recomendación estandarizada de una herramienta puede ser correcto desde el rol formal del auditor, pero ignora que no todo funciona como se espera en el papel. Hay conocimiento que solo se adquiere haciendo: no es la teoría sino la práctica la que hace al maestro.

2. Leer y validar la información que allega el auditado.

Cuando se recibe información sobre un "positivo imposible", es importante leerla con atención. Puede contener un aporte nuevo o un aprendizaje valioso. De la misma forma en que el auditado lee y estudia el informe del auditor, sería deseable que este último se tomara el tiempo para analizar las respuestas que recibe. En más de una ocasión, trabajando con firmas auditoras de talla mundial, hemos constatado con sorpresa lo escasa —o prácticamente nula— que es la lectura de las respuestas del auditado. En ocasiones pareciera que solo se allegan como parte de un procedimiento mecánico.

3. Asumir el caso auditado como una construcción colectiva y personalizada.

¿Cuál es el propósito de una revisión de vulnerabilidades? En algunos casos es innegable: evaluar y dictaminar hechos cumplidos, en especial cuando se asume como una herramienta para el establecimiento de responsabilidades. Sin embargo, la mayoría de las revisiones no suceden “cuando ya no hay nada que hacer”, sino justamente se ejecutan para prevenir posibles riesgos y es aquí donde sugerimos cambiar de enfoque: porque no asumir que el objetivo real de una prueba de vulnerabilidades es la construcción colectiva de la seguridad sobre los instrumentos auditados.

Cada nueva revisión de vulnerabilidades debería apoyarse en el conocimiento acumulado de las anteriores y no solo en el seguimiento de la calificación obtenida. Su propósito debería propender por una comprensión profunda de la realidad del auditado: su arquitectura, sus restricciones y su contexto, entre otros elementos particulares para cada caso. Personalizar el proceso da espacio para que auditores y auditados desarrollen una comunicación fluida que permita evolucionar el proceso sobre la base del conocimiento previo y el horizonte del propósito común. 

4. Propiciar la comunicación técnica entre auditor y auditado.

No se termina de comprender muy bien por qué, en ocasiones, la comunicación entre auditor y auditado se percibe como sospechosa o como un intento por manipular el proceso, cuando su objetivo es precisamente lo contrario: contribuir a eliminar las fricciones procedimentales en pro de una seguridad técnica lo más robusta posible.

En consecuencia, la invitación es a propiciar la comunicación más que a limitarla, eso si en el marco de una sana independencia y privilegiando ante todo el rigor técnico de ambas partes. 

5. Compartir el conocimiento generado.

Si los auditores consideran viable el análisis juicioso de los “positivos imposibles” que se sugirió antes, podrían también ampliar el alcance de ese conocimiento en beneficio de sus demás clientes, divulgándolo con la debida anonimización. En algunos casos parece ser una práctica que ya existe, aunque curiosamente la documentación disponible proviene casi siempre de contextos globales, más que de escenarios locales más cercanos a la realidad de los auditados.

Compartir activamente los “positivos imposibles” puede ayudar además a mejorar las herramientas de auditoría, a incrementar el valor percibido de la misma auditoría y a elevar el nivel de seguridad del ecosistema en su conjunto.

Una cosa más: coordinar mejor las pruebas ejecutadas en silencio.

Las pruebas de vulnerabilidad no anunciadas tienen su lógica: el efecto sorpresa puede revelar vulnerabilidades que de otro modo quedarían ocultas. Sin embargo, cuando se coordinan deficientemente, los desarrolladores o quienes dan soporte a los sitios Web o aplicaciones terminan enterándose de los eventos porque surgen contingencias de servicio inesperadas e indeseables. Un mínimo de coordinación no invalida los resultados: si el auditado tiene brechas reales en su sistema, ni siquiera el preaviso le permitirá resolverlas a tiempo. La sorpresa total no es condición indispensable para obtener resultados honestos.

En definitiva, las pruebas de vulnerabilidad son una herramienta valiosa e imprescindible en la construcción de entornos digitales seguros. Pero, como toda herramienta, su efectividad depende de cómo se usa. Reconocer sus propias vulnerabilidades, abrir canales de diálogo genuino con los auditados y evolucionar hacia un modelo más colaborativo no debilita la auditoría: la hace más inteligente, más precisa y, en última instancia, más útil.