Antes de enviar esse ficheiro HAR, leia o que ele contém
«Poderia enviar-nos um ficheiro HAR?» é um pedido razoável — e uma das entregas de ficheiros mais casualmente perigosas do trabalho quotidiano de suporte. Um ficheiro HAR é uma gravação completa de uma sessão do navegador: cada pedido e cada resposta, com os cookies, cabeçalhos de autorização, tokens e conteúdo de formulários que os fizeram funcionar. É exatamente o que um engenheiro de suporte precisa para reproduzir o seu problema, e exatamente o que um atacante quereria para reproduzir a sua sessão. Este artigo explica o que é um ficheiro HAR, como capturar um no Chrome, Edge ou Firefox, o que ele vaza, e como inspecioná-lo e redigi-lo antes de ir a qualquer lado.
O que é um ficheiro HAR
HAR — HTTP Archive — é um formato JSON para gravar tráfego HTTP, padronizado na especificação HAR 1.2 e exportado pelas ferramentas de desenvolvimento de todos os principais navegadores e por proxies de depuração como o mitmproxy. O ficheiro contém um objeto log com um array entries: uma entrada por pedido, cada uma com o método e o URL completo, os cabeçalhos de pedido e resposta, os cookies em ambas as direções, a cadeia de consulta dividida em parâmetros, qualquer corpo POST, o estado, tamanho e tipo de conteúdo da resposta, e os tempos divididos por fase — DNS, ligação, TLS, envio, espera, receção.
Por outras palavras, não é uma captura de ecrã do problema; é o problema, reproduzível. Tudo o que consome tráfego HTTP trabalha com o formato — ferramentas do navegador, analisadores de desempenho, engenheiros de suporte e, cada vez mais, agentes: a pilha REA tratada em podem os agentes de IA fazer engenharia reversa da sua app? lê capturas HAR nativamente, porque para muitas aplicações o tráfego da API explica mais do que o código. Essa utilidade é exatamente a razão pela qual o ficheiro merece uma leitura antes de merecer um envio.
Porque é que as equipas de suporte e os fornecedores pedem um
Porque põe fim às discussões. «A página estava lenta» torna-se uma cascata com pedidos nomeados e tempos. «A API falhou» torna-se o pedido exato que devolveu 500, com a carga exata e os cabeçalhos exatos. «Na minha máquina funciona» deixa de importar, porque a gravação é da sua máquina, da sua rede, da sua conta, no momento em que falhou. Um bom engenheiro de suporte consegue fazer mais com um ficheiro HAR honesto do que com uma semana de capturas de ecrã e memórias.
É também por isso que o pedido é tantas vezes reencaminhado sem pensar. O ticket diz «anexe um HAR», o utilizador exporta um em trinta segundos, e o ficheiro —gravado enquanto estava com sessão iniciada, a fazer trabalho real— começa a viajar: para um sistema de tickets, um fio de correio, por vezes um fórum público ou uma unidade partilhada, acumulando cópias em cada salto. Ninguém nessa cadeia é exatamente descuidado; o formato simplesmente esconde o que contém. Um ficheiro .har parece um diagnóstico inerte. Assemelha-se mais a um molho de chaves.
Como capturar um no Chrome, Edge ou Firefox
No Chrome ou Edge: abra a página, prima F12 para as DevTools e vá ao painel Rede (a referência de rede das Chrome DevTools documenta cada controlo). Certifique-se de que o botão vermelho de gravação está ligado e marque Preservar registo se o problema atravessar uma navegação. Reproduza o problema uma vez, do princípio ao fim. Depois clique com o botão direito em qualquer pedido da lista e escolha Guardar tudo como HAR com conteúdo (o Edge formula-o como guardar o registo de rede). No Firefox o fluxo tem a mesma forma: DevTools → Rede, reproduzir, clique direito → Guardar tudo como HAR.
Dois hábitos de captura importam mais do que qualquer definição. Primeiro, grave a sessão mais curta que mostre o problema: cada minuto extra de navegação é tráfego extra — e segredos extra — no ficheiro, incluindo o que outros separadores e pedidos em segundo plano estavam a fazer. Segundo, se puder, reproduza o problema num perfil de navegador novo ou numa janela privada, com sessão iniciada apenas no serviço em questão. Uma captura de um perfil limpo contém essa única sessão e nada mais: sem separador do banco, sem correio web, sem tokens de outras aplicações a viajar dentro.
O que ele vaza
A sua sessão, em primeiro lugar. Os cabeçalhos Cookie e Set-Cookie e as listas de cookies transportam os seus identificadores de sessão, e a maioria dos cookies de sessão são credenciais ao portador no sentido mais simples: quem apresentar um é tratado como você até expirar ou ser revogado. O cabeçalho Authorization acrescenta tokens ao portador e, por vezes, credenciais Basic. Nada no formato marca estes valores como especiais; são apenas cabeçalhos, gravados fielmente.
Depois, as coisas que ninguém considera cabeçalhos. Os tokens viajam nos URLs a toda a hora — chaves de API, ligações de reposição de palavra-passe e verificação de correio, URLs de descarregamento assinados, retornos de chamada OAuth — e o HAR grava o URL completo mais a cadeia de consulta dividida para leitura fácil. Os corpos POST transportam o que os formulários transportavam: a palavra-passe com que iniciou sessão durante a captura, edições de perfil, mensagens, dados pessoais. Os corpos de resposta podem trazer a mesma classe de dados de volta. Um ficheiro HAR de uma sessão real é, com efeito, uma transcrição parcial da sua conta — é por isso que as ferramentas que leem o tráfego de rede na linha, como o PCAP Analyzer, e as que o leem no navegador, como esta página, são feitas para mostrar as credenciais com clareza, para que veja o que tem nas mãos.
Inspecione-o e redija-o antes de o enviar
Portanto: abra o ficheiro antes de qualquer outra pessoa. É para isso que serve o HAR File Analyzer deste site — largue o .har na página e ele é analisado localmente, no seu dispositivo, nunca enviado, com os valores sensíveis mascarados por predefinição: cabeçalhos Authorization, Cookie e Set-Cookie, cada valor de cookie, e qualquer cabeçalho, parâmetro de consulta, campo de formulário ou chave JSON cujo nome pareça um token, uma chave, um segredo, uma sessão ou uma palavra-passe. Reveja o resumo e os pedidos mais lentos e maiores; verifique que hosts aparecem — uma captura por vezes contém tráfego de sites que nem estava a ver — e use o interruptor «mostrar valores», apenas no seu ecrã, se precisar de confirmar o que está realmente lá dentro.
Depois descarregue o .har redigido e envie esse em seu lugar. A redação mantém a estrutura de que um engenheiro de suporte precisa — as mesmas entradas, cabeçalhos, URLs como formas, estados e tempos — e substitui os valores de credencial pelo texto literal REDACTED, em cabeçalhos, cookies, cadeias de consulta, dados de formulário e corpos JSON por igual. Um limite está impresso na ferramenta e repete-se aqui: um corpo POST que não seja JSON nem dados de formulário comuns não pode ser analisado com segurança, pelo que é mantido sem alterações — se a sua captura contiver um corpo assim, leia-o você mesmo antes de o ficheiro viajar. O resumo CSV mascarado existe pela mesma razão: é o ficheiro que anexa quando o engenheiro pede «apenas a lista de pedidos».
O que a redação não pode fazer
A redação remove as chaves; não remove o mapa. Um HAR redigido continua a mostrar os seus hosts e endpoints, os seus nomes de parâmetros, a forma e o tamanho das respostas, a sequência e os tempos das chamadas — um esboço funcional da API da sua aplicação, que em si mesmo pode ser informação que não publica. Também não pode recolher cópias: quando um ficheiro em bruto entrou num sistema de tickets ou numa caixa de entrada, redigir a sua cópia não muda nada na deles. Partilhe o ficheiro redigido pelo canal privado que o fornecedor lhe deu — o próprio ticket, não uma publicação pública nem uma ligação pública — e peça, no ticket, que o ficheiro seja apagado quando o caso fechar. Organizações de suporte respeitáveis fazem isto rotineiramente; pedir não custa nada.
E se um HAR sem redação já escapou — enviado para o endereço errado, anexado a um problema público, deixado numa pasta partilhada — trate a sessão como exposta, porque está: termine a sessão do serviço (o que normalmente invalida a sessão do lado do servidor), inicie sessão de novo e rode quaisquer chaves de API que aparecessem nele. É a mesma regra que para qualquer credencial vazada, e é a razão pela qual as letras pequenas das outras ferramentas de ficheiros deste site são idênticas — o Binary File Inspector lê executáveis localmente pela mesma razão que esta página lê capturas localmente: os ficheiros que mais precisam de inspeção são exatamente os que não devem ser enviados para a fazer.