promo2024.cliente.cl apuntando a un sitio de campaña en Heroku, terminó la campaña, alguien borró la app — pero nadie tocó el DNS.
Resultado: un atacante crea una cuenta en Heroku, reclama exactamente el mismo nombre que tenía la app borrada, y ahora promo2024.cliente.cl resuelve a un servidor controlado por él. Con TLS válido. En tu zona.
A esto se le llama subdomain takeover, y es una vulnerabilidad de impacto alto que vive en el espacio entre “responsabilidad de DevOps” y “responsabilidad del equipo que usa el SaaS”. Por eso suele quedar sin dueño.
sub.cliente.cl. → algo.saas.com.sub.cliente.cl → CNAME a algo.saas.com → el contenido del atacante.El atacante puede ahora:
.cliente.cl (si tu apex setea cookies sin Path estricto).*@sub.cliente.cl si setea MX (escenario más raro pero posible).Cualquier SaaS que use CNAME a hostnames internos y permita claim libre. La lista cambia con el tiempo — muchos proveedores arreglaron el bug exigiendo verificación de ownership — pero a 2026 los patrones más comunes siguen siendo:
*.herokuapp.com para apps borradas.Cada proveedor tiene un “fingerprint” — texto en la respuesta HTTP que indica “este nombre no está reclamado”. Por ejemplo, GitHub Pages devuelve "There isn't a GitHub Pages site here.", Heroku devuelve "No such app". Herramientas de detección como subjack y takeover usan exactamente esa lista.
# 1) ¿el sub tiene CNAME?
dig +short CNAME sub.cliente.cl
# 2) ¿resuelve a una IP?
dig +short A sub.cliente.cl
# 3) ¿qué responde el destino?
curl -sI https://sub.cliente.cl/
curl -s https://sub.cliente.cl/ | head -20
Las señales rojas:
dig A no resuelve a nada → posible NXDOMAIN del target."No such app", "There isn't a GitHub Pages site here", etc.).Inventario de subdominios desde CT logs:
curl -s 'https://crt.sh/?q=%25.cliente.cl&output=json' \
| jq -r '.[].name_value' \
| tr ',' '\n' | sort -u > subs.txt
Después corrés algo como subjack contra esa lista. Lo importante: el inventario debe rehacerse seguido, porque CT logs solo te dan dominios que tuvieron cert TLS en algún momento, y los CNAME a SaaS típicamente disparan eso (los SaaS auto-provisionan TLS).
La detección es relativamente fácil. Lo difícil es que el patrón no reaparezca, y eso requiere disciplina organizacional, no técnica.
Tu zona DNS debería estar en git, o al menos exportarse periódicamente a un repo. Cualquier CNAME hacia un host externo necesita un comentario que diga para qué servicio es y quién lo creó. Si nadie reconoce el CNAME, candidato a borrar.
Varios proveedores hoy permiten “domain verification” — un TXT record en tu zona que prueba que sos vos el dueño. Si el SaaS lo soporta, activalo. Eso bloquea el claim externo aunque el CNAME quede huérfano.
Una auditoría manual cada 6 meses NO sirve. El CNAME huérfano puede aparecer mañana y ser reclamado pasado mañana. La detección efectiva es diaria, automatizada, con alerta al equipo de seguridad cuando aparece un nuevo huérfano.
Es exactamente el problema que nos llevó a construir el Dangling Monitor de Asentic — auto-descubre subdominios desde CT logs, clasifica cada uno en 5 estados (healthy, dangling-cname-nxdomain, dangling-cname-saas-claimable, dangling-ip-recycled, dangling-ns) y alerta cuando aparece uno nuevo o cuando uno existente cambia de estado. El servicio corre como monitoreo continuo con cadencia diaria y entrega los hallazgos por email.
Ofuscando contexto:
eventos2019.universidad.cl apuntaba a un Heroku que se borró en 2020. Detectado en 2026, reclamable. Reclamamos nosotros antes que cualquiera externo y lo entregamos al cliente para que limpie el DNS.legacy-shop.retail.cl apuntaba a un Shopify retirado hacía 18 meses. El CNAME estaba documentado en una hoja Excel que nadie revisaba.docs.empresa.cl → GitHub Pages, repo archivado por un ex-empleado. Cuenta personal, no organizacional. El nombre quedó claimable cuando GitHub borró el repo automáticamente por inactividad.El patrón común: nadie sabía que el CNAME existía. No es un problema técnico, es un problema de inventario.
Si tu zona DNS tiene más de 20 subdominios y nunca corriste un check de takeover, asumí que tenés al menos uno. La probabilidad sube con cada equipo que usa SaaS sin coordinación con seguridad — marketing, eventos, dev, customer success.
La detección manual te resuelve el problema de ahora. La detección continua te lo resuelve para siempre.
]]>Strict-Transport-Security (HSTS) le dice al browser que tu sitio se accede SIEMPRE por HTTPS. La primera vez que un visitante llega por HTTPS y recibe el header, lo guarda; cualquier intento futuro de cargar el sitio por http:// se reescribe a https:// antes de salir del browser.
Es el control que cierra el último hueco que dejó la migración a HTTPS: el primer http:// que un usuario tipea o que un link viejo apunta. Sin HSTS, ese primer request va en claro y puede ser interceptado para hacer downgrade (TLS stripping).
El problema: HSTS es pegajoso. Una vez que un browser lo memoriza, no hay forma práctica de bajarse rápido si te equivocaste. Por eso vale la pena entender qué activás antes de pegarlo.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Tres piezas, cada una con su trade-off:
max-age=63072000 — segundos que el browser memoriza la política. 63072000 = 2 años. Lo mínimo razonable para producción es 6 meses (15552000). Menos de eso es práctica de “estoy probando”.includeSubDomains — extiende la regla a TODOS los subdominios del host actual. Es lo que sube la postura de “tu apex está protegido” a “tu zona DNS entera está protegida”.preload — declara intención de aparecer en la HSTS preload list. Los browsers traen esa lista hardcoded; tu sitio queda protegido antes del primer request. Es la única forma de cerrar el “primer-request gap” del 100%.includeSubDomainsEste es el campo que más se equivoca. Implica que cualquier subdominio bajo tu zona también va a forzarse a HTTPS.
Caso real que vemos a menudo:
cliente.cl está en HTTPS con cert válido. Se le activa HSTS con includeSubDomains.cliente.cl tiene un legacy.cliente.cl viejo, sin cert, sirviendo un sitio interno por HTTP plano (intranet, monitoreo Grafana, lo que sea).cliente.cl, ese mismo browser ya no puede entrar a legacy.cliente.cl por HTTP. Y como no tiene cert TLS, tampoco por HTTPS. El subdominio queda inalcanzable hasta que el max-age expire.La lógica defensiva es la correcta — un atacante que controle DNS del subdominio podría exfiltrar cookies del apex si HSTS no aplicara a subs. Pero en práctica te tomás el tiempo de inventariar todos tus subs antes de prender la regla.
La receta que usamos en clientes:
max-age corto, sin includeSubDomains, sin preloadStrict-Transport-Security: max-age=300
Cinco minutos. Si rompés algo, en 5 minutos los browsers olvidan. Lo dejás 24-48 horas en producción para verificar que el apex realmente sirve TLS bien (no hay request mixto, no hay redirect-loop, todo funciona).
max-age 6 meses, sin includeSubDomains todavíaStrict-Transport-Security: max-age=15552000
Lo dejás 1-2 semanas. Esto ya te da la protección real para el apex.
includeSubDomainsAntes de agregarlo, listá todos tus subs:
dig +short NS cliente.cl
dig +short ANY cliente.cl
# o consulta los CT logs:
curl -s 'https://crt.sh/?q=%25.cliente.cl&output=json' | jq -r '.[].name_value' | sort -u
Para cada uno, verifica:
Si todos sirven HTTPS bien, agregás includeSubDomains. Si hay alguno HTTP-only, primero lo migrás a HTTPS o lo retirás del DNS.
Strict-Transport-Security: max-age=15552000; includeSubDomains
Una semana más en este estado.
max-age 2 años + preloadCuando ya estás seguro de que todo el ecosistema soporta TLS y querés cerrar el primer-request gap:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Submitís el dominio en hstspreload.org. Toma 1-3 meses entrar en la próxima release de Chromium, después Firefox/Safari/Edge la heredan.
Importante: una vez en la preload list, salir es lento. Solicitar la remoción puede tomar meses y los browsers viejos pueden quedarte preloaded por años. No actives preload mientras dudes.
.htaccess o vhost<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>
El flag always es importante: sin él, Apache aplica el header solo en respuestas 200; con always también lo manda en 30x/40x/50x, donde tradicionalmente se “olvida” — y es justamente en un 301 HTTP→HTTPS donde más útil resulta.
HSTS asume que tu sitio responde por HTTPS. El redirect HTTP→HTTPS debe estar antes:
<VirtualHost *:80>
ServerName cliente.cl
ServerAlias www.cliente.cl
Redirect permanent / https://cliente.cl/
</VirtualHost>
O en .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
El header HSTS debe servirse desde HTTPS (los browsers ignoran HSTS recibido por HTTP), así que el vhost :443 es el que lleva el Header always set.
Si estás detrás de CF (o cualquier CDN), tenés dos opciones para servir HSTS:
En la práctica, ambos: el origen lo manda Y CF lo refuerza. Cloudflare detecta duplicados y deja uno solo.
# verifica que el sitio sirve HTTPS bien
curl -sI https://cliente.cl/ | grep -i "strict-transport"
# verifica que ningún subdominio queda HTTP-only:
for sub in www app api blog dashboard mail; do
echo "--- $sub.cliente.cl ---"
curl -sI --max-time 5 https://$sub.cliente.cl/ 2>&1 | head -1
done
# debería verse el header completo
curl -sI https://cliente.cl/ | grep -i "strict-transport"
# Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
# verifica que el redirect 301 desde HTTP funciona
curl -sI http://cliente.cl/ | head -5
# debería devolver 301 hacia https://...
hstspreload.org hace los checks por vos: header presente, max-age suficiente, includeSubDomains, preload, redirect 301, cert válido, subdominios accesibles por HTTPS. Si fallás algún check, te dice cuál — y mejor arreglarlo antes que después.
Si pegaste HSTS y querés revertir:
max-age a 0 (no quites el header). Los browsers que reciban max-age=0 borran la entrada. Tardás max-age original en cubrir a todos los visitantes que tuvieron la versión anterior.El Asentic FreeScan reporta tres patrones distintos:
max-age < 6 meses te deja una ventana de exposición innecesaria.includeSubDomains o sin preload — Info. Eligible para subir la postura, no es un riesgo per se.La distinción importa porque “no implementado” y “implementado pobre” se ven igual en una auditoría superficial, pero requieren acciones distintas.
HSTS es de los headers con mejor ratio efecto/esfuerzo. La parte difícil no es el header en sí — son tres líneas de Apache — sino el inventario de subdominios que hay que hacer antes para no romper el ecosistema. Dedicarle un día a eso y migrar gradualmente vale el costo de la postura final.
Si tu sitio ya sirve HTTPS hace tiempo, lo más probable es que el camino al preload esté a una semana de distancia.
<script> malicioso, el browser se niega a ejecutarlo si no encaja en la política. También bloquea exfiltración a dominios no listados, frena form-jacking y reduce el blast radius de un plugin comprometido.
El problema: en WordPress muy pocas instalaciones la tienen bien configurada. Las dos rutas habituales son:
default-src * o script-src 'self' 'unsafe-inline' 'unsafe-eval' — escrita para que “no rompa nada”, lo que en la práctica equivale a no tener CSP.Este post es la receta que usamos cuando tenemos que llevar un WordPress real desde “sin CSP” hasta “CSP estricta funcional”, sin pasar por el infierno del soporte llamando porque el admin no carga.
La política se envía como cabecera HTTP (Content-Security-Policy: ...) o como <meta>. Cada directiva define qué orígenes están autorizados para cargar un tipo de recurso:
script-src 'self' — sólo JS del mismo origen.script-src 'self' https://www.googletagmanager.com — JS del mismo origen + GTM.script-src 'self' 'sha256-abc...' — JS del mismo origen + un script inline cuyo contenido tiene ese hash.script-src 'self' 'nonce-XYZ' — JS del mismo origen + scripts inline marcados con nonce="XYZ".Cuando el browser ve un recurso que no encaja, lo bloquea y opcionalmente reporta. Mientras más estricta la política, mejor protege, pero también más fácil es que algo deje de funcionar. El truco está en saber qué relajar y qué mantener.
WP es un campo minado para CSP por cinco razones, todas estructurales:
wp-admin/ está lleno de <script> inline con configuración por request (nonces, userSettings, traducciones). Sin 'unsafe-inline' ni hashes/nonces, el panel deja de funcionar.<script> inline con datos por request. El contenido cambia entre páginas — los hashes estáticos no sirven.wp_add_inline_script y wp_localize_script. WordPress mismo expone APIs para que los plugins inyecten configuración inline. El core lo hace, los themes lo hacen.?ver= cachebuster, vas a tener URLs ligeramente distintas por release.La conclusión práctica: una CSP estricta para WordPress requiere conocer qué carga tu instalación específica. No hay una política universal copy-paste que funcione bien.
El error más caro es publicar la CSP en modo enforcement sin medir antes. Si te equivocas, el sitio se cae para los visitantes (o peor: para los admins, y vuelves a quedar bloqueado tú).
El header Content-Security-Policy-Report-Only hace exactamente lo mismo pero sin bloquear. El browser sólo reporta las violaciones que habrían ocurrido. Con eso medimos durante 1-2 semanas qué se rompería con la política propuesta, y la ajustamos antes de enforcement.
Flujo recomendado:
Report-Only durante ~2 semanas.Content-Security-Policy) cuando los reports queden estables.Lo mínimo: un script que reciba el JSON POST y lo escriba a log. Si no quieres mantener uno, report-uri.com ofrece un free tier suficiente. Para WordPress, un endpoint custom en un plugin propio basta:
add_action('rest_api_init', function () {
register_rest_route('csp/v1', '/report', [
'methods' => 'POST',
'callback' => function ($request) {
$body = $request->get_body();
error_log('[CSP] ' . $body, 3, WP_CONTENT_DIR . '/csp-reports.log');
return new WP_REST_Response(null, 204);
},
'permission_callback' => '__return_true',
]);
});
Y en la cabecera: report-uri https://tu-sitio.cl/wp-json/csp/v1/report;. Para CSP 3, también: report-to csp-endpoint; con el grupo definido vía Report-To (más nuevo, no todos los browsers lo soportan aún — mantener ambos por un tiempo).
Para no caer en 'unsafe-inline', necesitas que los inline scripts que sí son legítimos pasen. Hay tres formas:
'sha256-<base64>'. Funciona bien para bloques fijos, ejemplo: un <script type="application/ld+json"> con tu Schema.org. Mientras el contenido no cambie, el hash sirve.
Para calcular el hash de un bloque (Python):
import hashlib, base64
script = '...' # contenido exacto entre <script>...</script>, sin las tags
print('sha256-' + base64.b64encode(hashlib.sha256(script.encode()).digest()).decode())
Limitación: si el bloque tiene cualquier cosa dinámica (timestamp, sessionId, nonce de form), el hash cambia por request y no sirve.
'nonce-<aleatorio-por-request>'. WordPress puede emitir un nonce CSP en cada response, y los plugins que cooperan lo van pegando a sus inline scripts:
add_action('init', function () {
if (!defined('CSP_NONCE')) {
define('CSP_NONCE', base64_encode(random_bytes(16)));
}
});
Y luego en el <script> que inyectas: <script nonce="<?php echo esc_attr(CSP_NONCE); ?>">. Cabecera: script-src 'self' 'nonce-<?php echo CSP_NONCE; ?>';.
El problema en WP: los plugins de terceros no usan tu nonce. Tienes que parchearlos uno por uno, o usar un plugin “CSP Manager” que intercepta wp_add_inline_script y le agrega el nonce. La práctica nuestra: vale la pena para inline propio, no perseguir cada plugin.
CSP 3 introduce 'strict-dynamic': si un script con nonce/hash crea otros scripts, los hijos heredan la confianza automáticamente. Es la dirección recomendada por el W3C para apps modernas. En WordPress es complicado porque WP no fue diseñado pensando en esto — el nonce tiene que llegar a todo el árbol de carga, lo que rara vez es práctico.
Suponiendo un WP institucional con Yoast, Cloudflare, Google Analytics y un form de contacto. La política mínima estricta razonable:
Content-Security-Policy:
default-src 'self';
base-uri 'self';
object-src 'none';
frame-ancestors 'self';
form-action 'self';
img-src 'self' data: https://secure.gravatar.com https://*.googleusercontent.com;
font-src 'self' https://fonts.gstatic.com data:;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
script-src 'self' 'nonce-XYZ' https://www.googletagmanager.com https://www.google-analytics.com;
connect-src 'self' https://www.google-analytics.com https://region1.google-analytics.com;
frame-src 'self' https://www.youtube-nocookie.com;
report-uri /wp-json/csp/v1/report;
upgrade-insecure-requests;
Notas sobre cada directiva:
default-src 'self': catch-all conservador. Cualquier tipo no listado cae acá.base-uri 'self' y form-action 'self': previenen ataques de manipulación del <base> y de redirección de submits.object-src 'none': nadie usa <object> / <embed> legítimamente en 2026. Cerrarlo.frame-ancestors 'self': reemplaza el viejo X-Frame-Options: SAMEORIGIN. Si tu sitio nunca se embebe, mejor 'none'.img-src 'self' data:: el data: se necesita para imágenes inline base64 que algunos plugins usan. Los hosts adicionales son típicos de Gravatar y Google sign-in avatars.style-src 'self' 'unsafe-inline': lamentablemente WordPress y la mayoría de los themes inyectan estilos inline. Por ahora 'unsafe-inline' queda. Una versión más estricta usa nonces para <style> también, pero el ROI es bajo (XSS via CSS exfil existe pero es marginal).script-src 'self' 'nonce-XYZ' + hosts GTM/GA: la línea más sensible. Aquí es donde el modo Report-Only te dice qué más necesitas.connect-src: dónde puede hacer fetch/XMLHttpRequest/WebSocket. GA usa region1.google-analytics.com para EU/CL traffic — no olvidar.frame-src: si embebes YouTube, usar youtube-nocookie.com (privacidad-first). Para Vimeo: https://player.vimeo.com.upgrade-insecure-requests: si algún src="http://..." quedó hardcoded, el browser lo upgradea automáticamente. Útil mientras limpias el sitio.Lo que no está: 'unsafe-inline' en script-src. Esa es la línea que más cuesta defender ante un equipo de devs apurados, pero también la que da el 80% del valor del header.
'unsafe-inline'Casi inevitable. La solución pragmática: aplicar dos políticas distintas según el path. En Apache:
<LocationMatch "^/wp-admin">
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; frame-ancestors 'self'"
</LocationMatch>
<LocationMatch "^/(?!wp-admin)">
Header always set Content-Security-Policy "[política estricta del frontend]"
</LocationMatch>
El admin queda con una política más laxa, pero los visitantes anónimos (99% del tráfico) reciben la estricta. Es un trade-off aceptable mientras planificas migrar el admin a nonces.
GTM es un container que carga scripts dinámicamente (Analytics, Ads, Hotjar, Facebook Pixel, …). Cada tag agregada en GTM añade un origen al script-src y al connect-src. La práctica nuestra: cada vez que el equipo de marketing agrega una tag en GTM, recibimos el report y agregamos el host. Si esto se vuelve un dolor crónico, vale la pena usar 'strict-dynamic' con nonce en GTM (Google lo soporta).
Necesita: script-src https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/, frame-src https://www.google.com/recaptcha/. Si lo olvidas, los forms con captcha quedan rotos sin error visible (el captcha simplemente no carga).
Cada uno agrega frame-src y muchas veces script-src/connect-src. La regla: prefiere el embed nocookie si existe. YouTube tiene youtube-nocookie.com, Vimeo respeta privacy mode. Reduce footprint de cookies y simplifica la política.
Pasarelas chilenas: Webpay 3D Secure abre un iframe a https://www.webpay.cl/. Khipu API: connect-src https://payment-api.khipu.com/. Stripe Elements: script-src https://js.stripe.com/, frame-src https://js.stripe.com/. Documenta esto explícitamente en tus runbooks — son los que más cuesta diagnosticar.
Si tienes Rocket Loader activado en Cloudflare, reescribe los <script> reales y los inyecta dinámicamente. Eso choca con CSP estricta. Dos opciones: deshabilitarlo (recomendado, su beneficio de performance es marginal con HTTP/2+Brotli activos) o marcar los scripts críticos con data-cfasync="false" para que no los toque.
CSP no es “ponla y olvídala”. Cada nuevo plugin, cada feature nueva, cada tag de marketing puede romperla. La rutina mínima:
Report-Only, valida 48h, luego enforce.El Asentic FreeScan revisa headers de seguridad incluido CSP. Detecta los tres patrones más comunes que vimos arriba: header ausente, header con 'unsafe-inline' o 'unsafe-eval', y header sin default-src o sin script-src (que dejan el resto sin restricción). El reporte distingue entre “no implementado” y “implementado pero ineficaz” — porque el segundo caso es engañoso para auditores que sólo verifican presencia del header.
Para validación manual:
curl -sI https://tu-sitio.cl/ — confirma que el header está siendo enviado.Refused to execute inline script because it violates the following Content Security Policy directive….CSP es una de esas herramientas que dan una ganancia de seguridad real con un costo de implementación que siempre subestimamos. Vale la pena pagarlo: cuando llegue el día en que un plugin se vea comprometido o un XSS pase la primera línea, el header es lo que decide entre un incidente menor y una filtración de datos.
Si tienes un WordPress en producción sin CSP, el primer paso es siempre el mismo: poner una política propuesta en Report-Only, dejarla correr una semana, y leer los reports. Todo lo demás sale de ahí.