Cómo eludir agentes JavaScript, CSP y crawlers (pruebas de seguridad del lado del cliente)

TL;DR:

• Los scripts del lado del cliente utilizados para comprobaciones de seguridad pueden volverse ineficaces mediante funcionalidades estándar del navegador, como las sobreescrituras de XHR.
• Aunque esto puede prevenirse, no hemos logrado encontrar ningún proveedor que haya implementado un método de prevención, lo que deja las soluciones de seguridad vulnerables a elusiones.
• Las soluciones sin crawler/escáner/agente sufren por diseño de visibilidad limitada. Esto permite que un actor malicioso detecte los escaneos y engañe al escáner de seguridad sirviendo código benigno, mientras sirve código malicioso a los usuarios finales.
• El propósito de este artículo es ayudar a comprender el riesgo de los ataques del lado del cliente y los exploits que los actores maliciosos utilizan para inutilizar las soluciones de seguridad. También ofrecemos las soluciones para prevenir estos métodos de elusión.

En este artículo:

• Por qué deberías probar tus herramientas de cumplimiento
• Cómo eludir agentes JavaScript
• Cómo eludir CSP
• Cómo eludir crawlers
• Consejos de defensa y alternativas más seguras
• Avisos legales y divulgación responsable

Propósito y alcance. Este artículo se publica únicamente con fines educativos y defensivos. Los ejemplos tienen como objetivo explicar el comportamiento general del navegador y las limitaciones de diseño que pueden afectar a las herramientas de seguridad del lado del cliente; no son un manual de ataque paso a paso y no están dirigidos a ningún proveedor, producto u organización específicos. No aprobamos el uso ilícito de ninguna de las técnicas aquí descritas. Si descubres una vulnerabilidad relacionada con el contenido de este artículo, sigue el proceso de divulgación responsable que se describe en la sección "Divulgación responsable" al final del mismo. Todas las pruebas se realizaron de conformidad con los términos de servicio aplicables del proveedor y la legislación vigente.

"En un mundo donde las herramientas de cumplimiento pueden fallar ante técnicas básicas de elusión, nadie está más seguro y la falsa sensación de seguridad agrava los problemas existentes."

- Simon Wijckmans, CEO, cside

Por qué deberías probar tus herramientas de cumplimiento del lado del cliente

Dudamos mucho antes de escribir este artículo. Por un lado, no queremos señalar a proveedores concretos. Por otro, cuando se venden soluciones de seguridad que pueden eludirse fácilmente, todos estamos en riesgo. Creamos cside para construir una internet más segura, con el objetivo de reducir la ansiedad de seguridad en línea.

A veces eso implica señalar debilidades en los perímetros de seguridad, especialmente cuando derivan de limitaciones bien conocidas de la plataforma.

Aunque entendemos que para muchas empresas el cumplimiento normativo requiere simplemente marcar una casilla, nosotros lo vemos como una oportunidad para mejorar la seguridad de una plataforma. Especialmente cuando esos requisitos de cumplimiento se crearon precisamente para prevenir la ejecución de ataques.

Imagina un detector de humo de última generación que detecta el fuego a la perfección, pero tiene el cable de alarma cortado antes de que pueda sonar la advertencia. La detección es perfecta, pero la respuesta nunca llega. Esta es la peligrosa realidad de algunas soluciones de seguridad del lado del cliente que operan dentro de un navegador web.

Cuando un navegador carga una página, los scripts se ejecutan en el mismo entorno JavaScript y pueden interactuar con objetos globales compartidos. En determinadas condiciones, esto puede permitir que un script observe o modifique a otro. Incluso las detecciones sofisticadas del lado del cliente pueden verse limitadas si se interrumpe su reporte de salida. Este es un riesgo práctico que los defensores deben considerar cuando dependen exclusivamente de telemetría del lado del cliente. Un script malicioso puede interferir con el reporte de salida de una herramienta de seguridad, lo que en algunos casos puede reducir significativamente la visibilidad sobre un incidente en curso.

Por esa razón, cside decidió no depender completamente de las detecciones del lado del cliente, optando en cambio por un enfoque más avanzado y matizado.

Cómo eludir un agente JavaScript

La forma principal en que un navegador se comunica con un servidor es a través de solicitudes de red, normalmente usando la API fetch o XMLHttpRequest (XHR). Para un desarrollador, estas pueden parecer partes fundamentales e inmutables del navegador. En realidad, son simplemente propiedades del objeto global window que cualquier script puede redefinir.

Muchos scripts legítimos interactúan con la API fetch; este es un enfoque común y generalmente conocido.

Sin embargo, un script puede aprovechar estas APIs para interactuar con las llamadas salientes de los proveedores de seguridad del lado del cliente. Esto se hace fácilmente:

• Redefiniendo window.fetch para inspeccionar o bloquear los reportes de seguridad salientes.
• Modificando XMLHttpRequest.prototype.send para interceptar y descartar alertas.
• Envolviendo estas funciones para alterar los payloads de las solicitudes, eliminar cabeceras de seguridad o registrar datos sensibles.

Veamos lo sencillo que es esto. Imagina que tu sitio carga dos scripts:

1. Un plugin de chat de terceros que ha sido comprometido.
2. Una herramienta de seguridad.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My Application</title>
  <script src="https://false-sense-of-security.com/security.js"></script>

  <script src="https://compromised-chat-plugin.com/plugin.js"></script>
</head>
<body>
  </body>
</html>

A continuación, el código que el plugin.js comprometido podría contener. Como hacen muchos scripts con fines legítimos, interactúa con la API del navegador XMLHttpRequest. A continuación se muestra un comportamiento general del software.

// NO EJECUTABLE: flujo conceptual del atacante (solo ilustrativo)
// Este bloque evita intencionadamente JS ejecutable. Explica los pasos
// de alto nivel que un atacante podría seguir para interferir con la telemetría del lado del cliente.
// NO pegues esto en un entorno JS esperando que se ejecute — es puramente descriptivo.
/
  Pasos conceptuales que un atacante podría usar (alto nivel):
    1) DETECT_TELEMETRY_SENDER(stack): usar heurísticas / marcadores en tiempo de ejecución para adivinar
       qué script está intentando enviar telemetría.
    2) INTERCEPT_OUTBOUND_CALL(request): cortocircuitar, modificar o descartar la solicitud.
    3) LOG_DECISION(info): registrar opcionalmente que se suprimió una llamada de telemetría.
/
/* ---------- Operaciones conceptuales (NO son funciones reales) ---------- */
DETECT_TELEMETRY_SENDER(stack)
// devuelve: SENDER_MATCHED | NO_MATCH
// NOTA: "stack" es una representación conceptual del contexto en tiempo de ejecución
INTERCEPT_OUTBOUND_CALL(request)
// posibles resultados (conceptuales): DROP | MODIFY(request) | FORWARD(request)
LOG_DECISION(info)
// registrar la decisión para análisis (conceptual)
/* ---------- Escenario simulado (solo texto) ---------- */
// Tiempo de ejecución simulado: el atacante inspecciona el call stack actual (conceptualmente)
SIMULATED_STACK = "...security.js at ..."
// Paso de detección conceptual
DETECT_RESULT => DETECT_TELEMETRY_SENDER(SIMULATED_STACK)  // => SENDER_MATCHED
// Decisión de interceptación conceptual
INTERCEPT_OUTCOME => INTERCEPT_OUTBOUND_CALL({ to: "/telemetry" })  // => DROP
// Registro simulado
LOG_DECISION("Telemetry report suppressed (conceptual)")
/* ---------- Salida de consola simulada (para comprensión del lector) ---------- */
// >> DETECT_TELEMETRY_SENDER(...) => SENDER_MATCHED
// >> INTERCEPT_OUTBOUND_CALL(...) => DROP
// >> LOG: "Telemetry report suppressed (conceptual)"

Con este comportamiento general del código en ejecución, tu herramienta de seguridad queda efectivamente bloqueada. Puede que aún detecte comportamiento malicioso, pero sus llamadas de auxilio (solicitudes fetch o XHR) son interceptadas y descartadas en el vacío. Nunca sabrás que tuvo lugar un ataque.

Cómo puede prevenirse esto

Prevenir este problema para las solicitudes fetch es muy sencillo: basta con guardar una copia local de la función, ni siquiera hace falta renombrarla.

// Almacena `fetch` localmente para reutilizarlo después:
const { fetch } = window;

// Usa la versión local de fetch más adelante en el código:
fetch(...)

Con XHR requiere un poco más de trabajo, pero sigue siendo posible con unas pocas líneas de código.

// Almacena los prototipos localmente para reutilizarlos después:
const { apply } = Reflect;
const { open, send } = XMLHttpRequest.prototype;
const { XMLHttpRequest } = window;

// En una parte asíncrona del código:
const request = new XMLHttpRequest();
apply(open, request, ["POST", "/endpoint"]);
apply(send, request, []);

Nuestro análisis de las metodologías de detección más comunes sugiere que estas soluciones podrían ser susceptibles a los conceptos de elusión documentados anteriormente.

Recomendamos encarecidamente que cualquier proveedor de seguridad estudie estos enfoques para ayudar a proteger a sus clientes.

Todo script de seguridad debe ejecutarse primero. De lo contrario, un actor malicioso puede secuestrar las APIs que el script de seguridad intenta proteger. Este es un requisito fundamental.

Cómo eludir una solución 'sin agente'

Muchos proveedores ofrecen un enfoque 'sin agente'. En la práctica, se trata de un escáner o crawler alojado en una plataforma cloud. Como cualquier aplicación, las solicitudes de red deben originarse en algún lugar. Y para la mayoría de estas soluciones, provienen de una dirección IP propiedad de proveedores cloud.

Cuando se realiza una solicitud de red, se envía una cabecera de solicitud que incluye varios datos de valor.

Host, User-Agent, Accept-Language, Referer (escrito intencionalmente con error) y muchos más.

La infraestructura de un script obtenido del lado del cliente ve estos valores y decide qué versión del script servir. Esto es lógico y existe por buenas razones. Una herramienta de marketing puede servir diferentes versiones de su script según el navegador desde el que se realiza la solicitud o según la ubicación del usuario, para simplificar el cumplimiento de privacidad. Del mismo modo, los anuncios publicitarios, por ejemplo, son simplemente aleatorios, cambian constantemente y son JavaScripts del lado del cliente. Los scripts del lado del cliente son funcionalidades dinámicas y muchas soluciones necesitan esa capacidad dinámica.

Sin embargo, esto representa una oportunidad para un actor malicioso. Para ilustrarlo:

// Pseudológica ilustrativa; no destinada a producción ni a uso indebido.
const CLOUD_ASNS = new Set([
// ASNs comunes de proveedores cloud. Añadir más si es necesario
16509, // AMAZON-02
14618, // AMAZON-AES
24940, // HETZNER
212317, // HETZNER
398657, // MICROSOFT AZURE DEDICATED
]);
export default {
async fetch(request) {
// el servidor añade información de red en la solicitud
const asn = request.xyz?.asn;
<span class="kw">const</span> body = CLOUD_ASNS
  ? <span class="str">`console.log("we're good");\n`</span>
  : <span class="str">`console.log("we're bad");\n`</span>;

<span class="kw">return new</span> Response(body, {
  headers: {
    <span class="str">"content-type"</span>: <span class="str">"application/javascript; charset=utf-8"</span>,
    <span class="str">"cache-control"</span>: <span class="str">"no-store"</span>,
  },
});

},
};

El ejemplo anterior puede ejecutarse en cualquier tipo de servidor web, incluidas plataformas PaaS sencillas que no requieren ningún nivel de verificación.

Lo que hace este script es bastante simple. Cuando una solicitud proviene de un proveedor cloud, sirve un script limpio. Cualquier otra solicitud recibe un script malicioso.

Por supuesto, el actor malicioso podría añadir más lógica. Por ejemplo, servir el script malicioso solo si las herramientas de desarrollador están cerradas y únicamente el 5% de las veces, dificultando así la detección mediante revisión manual.

Esto puede reducir sustancialmente la visibilidad que tiene una solución basada en crawlers ante ataques dirigidos.

Usar un proxy residencial para parecer un usuario residencial normal es poco probable que marque una diferencia significativa. Un actor malicioso puede igualmente detectar el uso de un proxy residencial.

El rango de red IPv4 cuenta con 4.300 millones de direcciones IP, IPv6 con 340 undecillones (sí, esa palabra existe), los user-agents del navegador cambian constantemente... hay niveles infinitos de entropía y un actor malicioso siempre puede muestrear un ataque. Al final, ningún método artificial para hacer que algo parezca humano es realmente humano. Los actores maliciosos con recursos encontrarán formas de diferenciar a un usuario humano real de un flujo de trabajo automatizado. Las páginas de marketing de los proveedores pueden hacerte creer lo contrario, pero los hechos técnicos son hechos técnicos.

Otro método sencillo consiste en realizar una sub-solicitud del lado del cliente basada en parámetros disponibles en el navegador. Esto permite utilizar toda la extensión de las APIs del navegador para decidir si realizar o no una sub-solicitud.

Muchas soluciones basadas en crawlers simplemente comprueban la URL de origen contra una lista de nombres de dominio maliciosos conocidos, obtenida de proveedores de feeds de amenazas. El problema con este enfoque es que un ataque dirigido no será marcado y que puede pasar mucho tiempo hasta que se detecte. Los actores maliciosos también pueden evitar fácilmente la detección de dominios maliciosos usando nombres de dominio de uso común como googletagmanager.com para alojar los scripts maliciosos.

Una solución basada en crawlers aborda una amenaza de seguridad dinámica con una mentalidad de seguridad estática. Aunque resulta conveniente, esto no funciona por diseño. Para ilustrar aún más este punto, repasemos algunos métodos de ataque comunes y cómo eluden la detección.

Ataques con geovalla (Geofenced attacks)

Qué son: Los ataques con geovalla solo sirven un script malicioso a usuarios en ubicaciones o rangos de IP específicos (por ejemplo, ciertos rangos de operadores móviles en el Reino Unido o la UE) y sirven un script benigno a todos los demás.

Por qué los escáneres no los detectan:

• Los escáneres, crawlers y herramientas "sin agente" casi siempre se ejecutan desde IPs de proveedores cloud o rangos de proxy conocidos.
• Los atacantes pueden mantener fácilmente una lista de ASNs cloud y evitar enviar payloads maliciosos a esas IPs.
• Como resultado, el escáner ve repetidamente el script "limpio" y nunca observa el ataque real.

Por qué cside los detecta:

• cside observa los scripts tal como se ejecutan en los navegadores de usuarios reales, en redes residenciales y móviles reales.
• Si un script se comporta de forma maliciosa para cualquier usuario real, cside puede detectar el comportamiento y, en modo gatekeeper, incluso bloquear el payload antes de que se ejecute.

En otras palabras, Reflectiz ve lo que los atacantes permiten que vean sus escáneres; cside ve lo que los atacantes realmente envían a tus usuarios.

Ataques dirigidos por User-Agent

Son ataques en los que un payload malicioso solo se inyecta en ciertos navegadores, por ejemplo selenium, Safari, Chromium o un sistema operativo específico.

La mayoría de los escáneres, crawlers y, en este caso, las soluciones 'sin agente' se originan desde un rango de cadenas User-Agent predecibles. Raramente emulan cabeceras de dispositivos móviles.

Y en los raros casos en que un escáner cambia sus User-Agents, el agente normalmente no se alinea con los payloads de solicitud reales. Los escáneres suelen ejecutarse en sistemas operativos basados en Linux, lo que significa que un actor malicioso notará, basándose en el paquete de solicitud TCP, qué sistema operativo se está usando realmente. Esto hace que el payload malicioso no se envíe al escáner, ya que Linux raramente es utilizado por un usuario humano real.

Ataques con ventana temporal (Time-Windowed Attacks)

Son ataques que solo se ejecutan en momentos específicos del día. Por ejemplo: fuera del horario de oficina, cuando los equipos de seguridad no están presentes. Los escáneres se ejecutan periódicamente, por lo que un enfoque acotado en el tiempo puede fácilmente resultar en que se escanee el script benigno, pero no el malicioso.

Ejecución de código oculta o condicional

Son ataques que aprovechan las acciones del usuario para inyectar un script malicioso. Aquí puede utilizarse toda la extensión de las APIs del navegador: por ejemplo, comprobar movimientos del ratón, requerir un cierto ritmo en la entrada del teclado, verificar la existencia de cookies, análisis de temporización (usado para detectar navegadores headless)...

Habitualmente, este método se usa para servir el payload malicioso solo una vez, de modo que un investigador de seguridad no pueda encontrarlo de nuevo. Esto es especialmente complicado, ya que las herramientas de desarrollador de los navegadores a menudo no almacenan los estados previos a su apertura, lo que hace necesario recargar la página.

Un escáner nunca podrá emular el comportamiento real de un usuario de la misma manera que lo haría un usuario real.

Payloads dinámicos por sesión

Son ataques en los que el actor malicioso genera automáticamente payloads maliciosos únicos para cada usuario real, usando técnicas como envolver scripts con claves dinámicas, JavaScript polimórfico, lógica estilo A/B testing... A menudo usando los indicadores de autenticación del usuario como condición para inyectar los payloads maliciosos.

Envenenamiento intermitente de la cadena de suministro

Este es un método extremadamente común en los ataques estilo Magecart. Un actor malicioso puede simplemente muestrear el ataque para servir el contenido del script malicioso solo al 1% de los usuarios. Este método dificulta mucho que un visitante note el ataque, ya que la inyección totalmente aleatoria del script hace que reproducir el ataque sea mucho más difícil.

Conclusión

Basándonos en las capacidades fundamentales del navegador documentadas públicamente y en la funcionalidad estándar de JavaScript, los enfoques basados en crawlers pueden enfrentarse a las limitaciones descritas anteriormente.

Animamos a los proveedores a documentar claramente dichas limitaciones y a no sobreestimar sus capacidades. Los clientes deben disponer de la información necesaria para tomar decisiones de despliegue informadas en beneficio de la seguridad de la web.

Cómo eludir CSP

Otro enfoque de seguridad de uso común son las políticas de seguridad de contenido (CSP).

CSP puede ser útil para limitar la exposición reduciendo el alcance de las fuentes permitidas. Sin embargo, muchos sitios web utilizan herramientas abiertas a todo el mundo para subir scripts. Si una política no es lo suficientemente estricta, esto llevará a una elusión sencilla. Pero incluso si la política es suficientemente estricta, un atacante puede optar por realizar el ataque de una manera que CSP no monitoriza.

Cómo funcionaría esto: una vez que un actor malicioso encuentra la manera de acceder a una aplicación web, puede inyectar una sub-solicitud a un contenedor de Google Tag Manager. Ejemplo:

<script async src="https://www.googletagmanager[.]com/gtm.js?id=GTM-XXXXXX"></script>

Dentro de este contenedor, pueden incluir cualquier script que deseen, incluyendo scripts en línea que son aún más difíciles de asegurar.

Dado que CSP no tiene contexto real del payload del script, la visibilidad es bastante limitada.

Algunas soluciones intentan cambiar esto realizando un fetch al script a posteriori.

Pero se presenta el mismo problema que con el crawler: cualquier cosa que parezca no humana probablemente recibirá una respuesta diferente a la que recibiría un usuario humano.

Aunque podrías especificar el contenedor de tag manager en el CSP, esto no es muy común. También hay otros dominios como "githubusercontent[.]com" que presentan este mismo problema.

Y en última instancia, si una fuente se ve comprometida, ya sea por un incidente en el proveedor o por la expiración del nombre de dominio, CSP no podrá ayudar.

A diferencia del método de script del lado del cliente, no hemos podido encontrar una técnica fiable dentro de CSP que evite usar un dominio de confianza como método de elusión. Los propietarios de los dominios podrían tomar medidas preventivas, pero hasta la fecha no lo han hecho. CSP tiene limitaciones, pero como en cualquier programa de seguridad, la defensa en capas es una buena práctica. CSP se está usando para más de lo que fue diseñado inicialmente.

Las empresas que adoptan CSP a menudo tienen dificultades para mantenerlo y lidian con interrupciones frecuentes de herramientas del lado del cliente cuando las políticas bloquean cambios.

cside participa activamente en organizaciones de estándares web para intentar mejorar la especificación de CSP y otros métodos como SRI.

Alternativas más seguras (el enfoque de cside)

El equipo de cside tiene una experiencia considerable en seguridad del lado del cliente. A lo largo de nuestra trayectoria, identificamos que los actores maliciosos operan con un nivel de sofisticación que supera a algunos enfoques de seguridad. Si la recompensa es alta, cualquier brecha en un modelo de detección de seguridad es una oportunidad para un actor malicioso.

Dadas las limitaciones de la especificación del navegador para la seguridad del lado del cliente, hemos tenido que ser creativos, razón por la cual abordamos la seguridad del lado del cliente de una manera diferente a cualquier otra solución del mercado.

• Modo Directo - El más sencillo: Comprobamos los comportamientos de los scripts en el navegador y obtenemos los scripts por nuestra parte. Luego verificamos que recibimos el mismo script. No nos interponemos en el camino de un script a menos que nos lo pidas explícitamente. Solo hay que añadir un script al sitio; tarda segundos.
• Modo Gatekeeper - El más seguro: Comprobamos los comportamientos de los scripts y cside se sitúa en el medio entre el tercero no controlado y el usuario final, solo para los scripts en los que aún no confías. Solo hay que añadir un script al sitio; tarda segundos.
• Modo Escaneo - El más rápido: Si no puedes añadir un script al sitio, cside lo escaneará. Utilizaremos la inteligencia de amenazas de cside recopilada por miles de otros sitios web con miles de millones de visitantes combinados para ayudar a asegurar tu sitio de la mejor manera posible.

La combinación de lo anterior nos acerca lo más posible a la cobertura total técnicamente alcanzable hoy en día.

Como beneficio adicional, con algunos de los enfoques que hemos adoptado hemos podido hacer que los sitios web sean más rápidos dependiendo de los scripts presentes en la página. Situar una solución en el medio solo ralentiza las cosas si ya están completamente optimizadas, lo cual a menudo no es el caso.

Con esto, cside ayuda a las empresas a lograr el cumplimiento normativo, ya sea en materia de seguridad o de privacidad.

cside contribuye activamente al W3C con la esperanza de crear conciencia sobre la seguridad del lado del cliente, con el objetivo de realizar ajustes en la especificación del navegador que permitan una seguridad del lado del cliente completamente a prueba de fallos.

En cside, capturamos ataques. Si estás leyendo este artículo, probablemente seas un objetivo de suficiente valor para que un actor malicioso invierta cierta capacidad mental en inspeccionar cómo funciona tu seguridad web. Es mejor estar seguro y asumir que un actor malicioso intentará eludir las soluciones de seguridad que utilizas. Así que usa soluciones que piensen un paso por delante.

Aviso legal y puerto seguro

Este artículo tiene únicamente fines informativos y educativos. No constituye asesoramiento legal, y las opiniones y el análisis técnico expresados son propios. Nada de lo aquí expuesto debe interpretarse como una admisión de responsabilidad por parte de ninguna de las partes.

Ninguno de los enfoques o fragmentos de código mencionados anteriormente son avanzados ni se usan exclusivamente con fines maliciosos. Se trata de casos de uso básicos de JavaScript; en ningún caso son propietarios. Los fragmentos compartidos se usan activamente en scripts del lado del cliente con fines legítimos. No somos responsables del uso de estas funciones básicas de JavaScript por parte de un actor malicioso.

Todo el código de ejemplo y el pseudocódigo son únicamente ilustrativos. Son intencionadamente genéricos, no propietarios y no están diseñados para ejecutarse en entornos reales. Su propósito es destacar consideraciones defensivas, no proporcionar a los atacantes exploits funcionales.

Ten en cuenta que intentar aplicar estas técnicas en sistemas que no son de tu propiedad, o sin permiso explícito, puede violar leyes como la Ley de Fraude y Abuso Informático de EE. UU. (U.S. Computer Fraud and Abuse Act), la Ley de Uso Indebido de Ordenadores del Reino Unido (UK Computer Misuse Act) o normativas similares en otras jurisdicciones.

Apoyamos activamente la investigación de seguridad de buena fe. Si sigues el proceso de Divulgación Responsable descrito a continuación, trataremos tu investigación como autorizada y no emprenderemos acciones legales contra ti. En resumen, este contenido se proporciona para ayudar a los defensores a reforzar las protecciones, no para facilitar comportamientos maliciosos.

Divulgación responsable

Si crees haber descubierto una vulnerabilidad relacionada con el contenido de este artículo (incluidos scripts de terceros o integraciones que mencionamos), por favor no publiques los detalles del exploit públicamente. En su lugar, envíanos un correo electrónico a

hello@cside.com con el asunto "Vulnerability report [short title]".

Incluye los pasos para reproducirlo, las URLs afectadas y un método de contacto seguro. Acusaremos recibo en un plazo de 5 días hábiles y coordinaremos la remediación. No emprenderemos acciones legales contra los informantes de buena fe que sigan estas directrices.