Sanitizador de Archivos HAR

Descripción general

Un archivo HAR es el registro que el propio navegador hace de una carga de página, exportado desde DevTools. Es el adjunto más útil que puedes poner en un informe de error del tipo «a mí me funciona», y también una de las cosas más peligrosas que puedes pegar en un gestor de incidencias público. La captura de una sesión autenticada contiene tu cookie de sesión, tu cabecera Authorization, cualquier código OAuth que estuviera en vuelo en ese momento, todos los formularios que enviaste y todos los cuerpos de respuesta que devolvió el servidor.

Esta herramienta reescribe la captura para que sobreviva la estructura y no los secretos. Conservas la lista de peticiones, los métodos, los códigos de estado, los nombres de las cabeceras, los tiempos y los tamaños — todo lo que un mantenedor necesita para razonar sobre tu problema — mientras que los valores que comprometerían tu cuenta se sustituyen por [REDACTED].

Cómo se usa

1. En DevTools, abre Network, haz clic derecho sobre la lista de peticiones y elige Save all as HAR.
2. Pega aquí el JSON (o abre el archivo y pega su contenido).
3. Lee el recuento de campos censurados y después repasa la salida.
4. Pulsa Download para guardar sanitized.har y adjunta ese archivo en lugar del original.

Qué se elimina

La captura guarda el mismo secreto en varios sitios a la vez, así que la herramienta tiene que limpiarlos todos. Dejarse uno es el fallo que de verdad importa: un archivo que parece saneado es peor que uno que evidentemente no lo está, porque lo vas a adjuntar sin pensarlo dos veces.

• Cabeceras. Cookie, Set-Cookie, Authorization y cualquier cabecera cuyo nombre contenga token, secret, credential, session o api-key. También Location, porque una redirección posterior a un callback de OAuth lleva el código de autorización en la URL.
• Arrays de cookies analizados. El HAR registra las cookies dos veces: una como la línea de cabecera cruda y otra como un array cookies[] de pares nombre/valor. Todos los valores de esos arrays se borran sin mirar el nombre, porque el nombre de una cookie no dice para qué sirve (s, _sess y SID son cookies de sesión en la vida real).
• Cuerpos de petición. Se borran tanto postData.text como los postData.params[] analizados, sin mirar los nombres de los campos. El campo de un formulario de inicio de sesión puede llamarse pass, otp o cvv, y ninguno de esos coincide con una lista de palabras clave que se te ocurriría escribir.
• Cuerpos de respuesta. Se borran por completo. Son la mayor fuente individual de divulgación accidental: una respuesta JSON de /api/me contiene el registro completo del usuario.
• Destinos de redirección y tramas WebSocket. response.redirectURL y los _webSocketMessages de Chrome, cuya primera trama es muy a menudo el handshake de autenticación.
• Dirección IP del servidor e iniciador. serverIPAddress expone el direccionamiento interno; el _initiator de Chrome guarda la URL completa del script que disparó la petición, cadena de consulta incluida.
• Parámetros de consulta. Cualquier parámetro cuyo nombre parezca una credencial: token, api_key, AWSAccessKeyId, signature, code, state, sid y todo lo que contenga key, secret o password. Los parámetros que no son secretos, como page y lang, se dejan tal cual para que las URL sigan siendo legibles.
• Títulos de página y referentes. El título de una página muchas veces es la propia URL, y una cabecera Referer posterior a un callback de OAuth lleva el código de autorización.

Qué se conserva a propósito

Hay dos categorías que se dejan intactas aunque un filtro tosco por palabras clave las cazaría, porque quitarlas destruye la razón por la que compartiste el archivo:

• Cabeceras de respuesta CORS. Access-Control-Allow-Origin y compañía no contienen ningún secreto, y un fallo de CORS es de entrada uno de los motivos más habituales para compartir un HAR. Censurar la respuesta a la pregunta deja la captura inservible.
• Desafíos de autenticación. WWW-Authenticate y Proxy-Authenticate describen qué esquema quiere el servidor. Eso es una pista, no una credencial.

Qué no puede eliminar

La censura basada en nombres tiene un límite duro, y conviene saber dónde está antes de adjuntar la salida a una incidencia pública.

• Secretos en la ruta de una URL. /reset/9f3c… e /invite/abc123 son indistinguibles de /users/42 si no conoces la ruta. Los segmentos de ruta se dejan intactos, porque quitarlos destruiría la lista de peticiones.
• Tokens en cabeceras personalizadas con nombres inocuos. Una cabecera llamada X-Client-Id que resulta que lleva un valor firmado no va a coincidir con ninguna palabra clave. Repasa tus propios nombres de cabecera antes de compartir nada.
• Datos personales en parámetros que no son secretos. Una dirección de correo en ?email= sobrevive, porque email es el nombre de un campo y no una credencial. Que eso importe o no depende de a quién le mandes el archivo.
• Las URL en sí. Los nombres de host internos, los dominios de staging y las rutas de la API se conservan todos, y juntos describen tu arquitectura.

La regla práctica: esta herramienta hace que una captura sea segura para adjuntarla a un ticket con un proveedor o a una incidencia en tu propio gestor. Trata «seguro para publicar en internet abierto» como un juicio aparte, que haces tú leyendo el archivo.

Notas

Los valores se sustituyen en lugar de borrarse, así que la forma del JSON no cambia y cualquier visor de HAR seguirá abriendo el resultado. La única excepción es content.encoding: cuando se sustituye un cuerpo de respuesta, se elimina la declaración base64 que describía los bytes originales, porque [REDACTED] no es base64 y un visor estricto fallaría al leerlo.

El contador informa de campos borrados o eliminados, no de secretos encontrados. La captura de un sitio estático sin cookies puede dar legítimamente un número alto, porque cada cuerpo de respuesta cuenta.

Una entrada que no es un HAR se rechaza en lugar de dejarse pasar. Una versión anterior de esta herramienta aceptaba cualquier JSON, procesaba cero entradas e informaba de «0 sensitive values redacted» como si fuera un éxito, devolviéndote el archivo original con un certificado de buena salud. Decirte que algo es seguro es aquí todo el producto, así que la herramienta ahora rechaza cualquier cosa que no tenga un array log.entries.

Si lo único que quieres es leer una captura y no compartirla, usa el visor de HAR. Enmascara los secretos en pantalla pero nunca reescribe el archivo, porque de cualquier modo nada sale de tu equipo.