Encabezados como bolsas
Los marcos de registro HTTP tratan los encabezados de la solicitud como una bolsa de pares clave-valor. La API de registro expone la bolsa completa. Los operadores habilitan el registro de encabezados para depuración: cuando una solicitud falla, los encabezados cuentan la historia. No hay lista de denegación integrada. No hay filtrado de credenciales en la documentación. Encabezados completos en disco.
Los encabezados de credenciales en una solicitud típica:
- Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... (token JWT u OAuth)
- Cookie: session=abc123; auth=xyz789
- X-API-Key: sk-live-abc123...
- X-Auth-Token: ghp_abc123... (patrón de token de acceso personal de GitHub)
Estos valores autentican la solicitud. Si se escriben en un archivo de registro, autentican cualquier solicitud.
El flujo de credenciales
Una credencial escrita en un archivo de registro no permanece en un solo lugar. Viaja:
1. El servidor web escribe en /var/log/nginx/access.log
2. El agente de rotación de registros (logrotate) copia a /var/log/nginx/access.log.1
3. El recolector de registros (Fluentd, Filebeat, Logstash) lee y envía al agregador
4. El agregador de logs (Elasticsearch, Splunk, Datadog) indexa y almacena
5. Se retiene durante 30-90 días según la política predeterminada
La credencial existe simultáneamente en las cinco ubicaciones. Revocar el token de sesión no elimina la credencial del agregador de logs. Permanece buscable, exportable y accesible para cualquiera con acceso a los logs durante todo el período de retención.
La ventana de exposición
Ventana de exposición de una credencial en memoria: max(duración de la sesión, tiempo de vida del proceso). Sesión: horas a días. Proceso: horas a semanas.
Ventana de exposición de una credencial en un log: max(duración de la sesión, retención de logs). Sesión: horas a días. Retención: 30-90 días.
Una credencial robada de la memoria requiere que el atacante esté presente durante la ventana de sesión. Una credencial robada de un log solo requiere acceso al agregador de logs, disponible de forma retroactiva, durante todo el período de retención.
MOAD-0003 vs MOAD-0004
MOAD-0003 (Contexto filtrado): una credencial en memoria se filtra al controlador de solicitudes incorrecto. Solo accesible durante la ventana del proceso, a través del grupo de subprocesos. Efímero.
MOAD-0004 (Secreto registrado): una credencial en disco persiste a través de la rotación, envío y agregación de registros. Accesible retroactivamente, para cualquiera con acceso a los registros, durante 30-90 días. Persistente.
La diferencia estructural: efímero frente a persistente. La corrección opera en una capa distinta.
Efímero vs Persistente
La distinción efímero/persistente determina la superficie de riesgo, la capa de corrección y los requisitos de respuesta a incidentes.
Lista de denegación de credenciales en la capa de serialización
La corrección: una lista de denegación de credenciales en la capa de serialización. Antes de que cualquier valor de encabezado llegue a la salida del registro, verifica el nombre del encabezado contra una lista de denegación. Reemplaza el valor con [REDACTED].
CREDENTIAL_HEADERS = {
'authorization',
'cookie',
'x-api-key',
'x-auth-token',
'x-csrf-token',
'proxy-authorization',
}
def sanitize_headers(headers: dict) -> dict:
return {
k: '[REDACTED]' if k.lower() in CREDENTIAL_HEADERS else v
for k, v in headers.items()
}La lista de denegación pertenece a la capa de serialización, no a la capa de consulta de registros. Redacción en la consulta de registros: se aplica después de que la credencial haya llegado al disco; el valor original sigue existiendo, solo queda oculto de la visualización. Redacción en la capa de serialización: la credencial nunca llega al disco. El valor original nunca entra en el archivo de registro, el transportador de registros ni el agregador de registros.
Pruebas de la lista de denegación
Tres patrones de prueba:
- Positivo: una solicitud con Authorization: Bearer token123 produce una entrada de registro con Authorization: [REDACTED]
- Negativo: una solicitud con Content-Type: application/json genera una entrada de registro con el valor intacto
- Insensible a mayúsculas: AUTHORIZATION: Bearer token123 también produce [REDACTED] (los nombres de encabezados HTTP no distinguen mayúsculas)
La lista de denegación requiere mantenimiento: nuevos patrones de encabezados de credenciales (por ejemplo, encabezados personalizados X-Service-Auth) necesitan ser añadidos explícitamente. La corrección es estructural pero no se mantiene sola.
Aplicar la lista de denegación
Un equipo configura el formato de registro de acceso de Nginx para incluir todos los encabezados de solicitud al depurar un incidente en producción. La configuración:
log_format debug_format '$remote_addr - $request - $http_authorization - $http_cookie';
access_log /var/log/nginx/debug.log debug_format;Resuelven el incidente e intentan eliminar la configuración de depuración, pero el cambio no llega a producción antes del siguiente ciclo de despliegue (7 días después).