Ta bort hemligheterna från loggar och HAR-filer innan du delar dem

"Kan du skicka mig en HAR-fil?" är en rimlig begäran från en supporttekniker och en farlig sak att efterleva utan omtanke. En HAR-export är en komplett inspelning av en webbläsarsession: varje begäran, varje svarshuvud, varje skickad cookie och ofta även svarsorganen. Att lämna över en oredigerad ger mottagaren möjlighet att agera som du på vilken sida som helst i den inspelningen, så länge som dessa sessioner lever.

Samma sak gäller, mindre självklart, för de loggklipp som folk klistrar in i biljetter, Slack-trådar och chattfönster hela dagen. Det är värt att ha en rutin.

Vad finns egentligen i en HAR-fil

HAR är JSON, och den är uttömmande till sin design. I en normal export hittar du:

• Sessionscookies för varje berört domän, i sin helhet, som skickat. Det här är den stora – en sessionscookie är en bärare, och mottagaren behöver inte ditt lösenord för att använda det.
• Authorization rubriker, inklusive bärartokens och grundläggande autentiseringsuppgifter, som är trivialt avkodningsbara.
• Tokens i frågesträngar. Länkar för återställning av lösenord, signerade webbadresser, API-nycklar som skickas som parametrar, OAuth-koder mitt i flödet.
• Begärande organ. Allt du skrev i ett formulär under inspelningen, inklusive inloggningsformuläret om inspelningen startade innan du loggade in.
• Reaktionsorgan. Beroende på exportalternativen, de faktiska uppgifterna – kundregister, kontodetaljer, interna API-nyttolaster.
• Allt annat du hade öppet. En HAR är per webbläsarflik, men analytics beacons, tilläggstrafik och bakgrundsuppdateringar från andra tjänster hamnar också i den.

De HAR fildesinfektionsmedel tar exporten och tar bort de autentiseringsbärande delarna – cookies, auth-rubriker, tokens – samtidigt som begäran och svarsstrukturen lämnas intakt, vilket är vad personen som felsöker ditt problem faktiskt behöver. Klistra in den, skaffa en rensad fil, bifoga den.

Titta på vad du skickar

Att desinficera blinda är bättre än att inte desinficera, men den användbara vanan är att leta först. Kopiera rubrikerna för den misstänkta begäran från dina dev-verktyg och kör dem genom HTTP header parser: det delar upp ett råblock i namn/värdepar som du kan läsa, vilket gör det uppenbart när det finns en X-Internal-Auth eller en leverantörsspecifik token-header som ett generiskt redigeringsmönster inte skulle ha känt igen som en hemlighet.

Kakor förtjänar sitt eget utseende. Klistra in en Cookie eller Set-Cookie linje in i cookie parser och du får varje kaka uppdelad med dess attribut — HttpOnly, Secure, SameSite, utgång. Det är en redaktionskontroll ("vilka av dessa är sessionstokens?") och en säkerhetsgranskning på samma gång: en sessionscookie utan HttpOnly eller med ett år långt utgång är ett fynd i sig, och du tittar redan på det.

Terminalutgången har två problem

Inklistrade terminalloggar innehåller hemligheter - anslutningssträngar, tokens i curl-kommandon, miljödumpar - och de har också ANSI-escape-sekvenser. Det är anledningen till att en färgglad stock förvandlas till ESC[0;32m ljud när den landar i en biljett, och de gör texten svår att läsa för alla och svåra för dig att söka. De ANSI stripper tar bort färg- och markörkontrollkoderna och lämnar texten.

Redigera sedan. De dataredaktor hittar de återkommande kategorierna – e-postadresser, IP-adresser, telefonnummer, kortnummer, nyckelformade strängar – och ersätter dem konsekvent, så att loggen fortfarande läses som ett sammanhängande spår istället för att bli en vägg av [REDACTED]. Konsistens spelar roll när du felsöker: om samma användar-ID ersätts med samma platshållare överallt, kan läsaren fortfarande följa en begäran genom femtio rader.

Mönstermatchning kommer inte att fånga en hemlighet som ser ut som vanlig text, så läs resultatet innan du skickar det. Interna värdnamn, kundnamn i fritextfält och filsökvägar som innehåller användarnamn är de tre sakerna som överlever varje automatiserat pass.

Redaktion är inte rotation

Den viktigaste punkten, och den som folk hoppar över: om en autentisering redan har skickats någonstans borde den inte ha tagits bort, att ta bort den från ett dokument gör ingenting. Mottagaren kan ha det. Det kan vara i ett e-postarkiv, ett biljettsystem, en chattbackend, någons lokala nedladdningsmapp eller en modellleverantörs loggar.

Rotera. Ogiltigförklara sessionen, återkalla token, rulla API-nyckeln. Rengör sedan filen. I den ordningen eftersom rengöringen tar en minut och rotationen är den del som faktiskt stänger exponeringen.

Att klistra in i ett chattfönster publiceras

Felsökning med en assistent är normalt nu, och en stackspårning med en anslutningssträng i går till en tredje part i samma ögonblick som du trycker på enter. Beroende på produkten och planen kan den texten behållas, granskas av en människa eller användas för utbildning. Behandla vilken pasta som helst i en värdmodell som en överföring till en extern part – eftersom det är vad det är – och sanera det precis som du skulle rensa en bilaga till ett externt e-postmeddelande.

Detta är fallet där lokal verktyg inte är en preferens utan hela poängen: alla verktyg som nämns här körs i din webbläsare, så den oredigerade versionen av filen laddas aldrig upp till någonting på väg att rengöras. Att sanera en hemlighetsbärande logg genom att klistra in den på en webbplats som bearbetar den på en server innebär att hemligheten redan har lämnats, hur den rensade utgången än ser ut.

En checklista värd att fästa

1. Spela in HAR i ett privat fönster med endast relevant flik öppen och börja spela in efter du har loggat in.
2. Kör exporten genom desinfektionsmedlet.
3. Öppna den rensade filen och sök efter den token, secret, key, auth, password och dina egna domännamn.
4. Skala ANSI-koder från valfri terminalutgång och reda ut identifierare.
5. Läs resultatet från början. Det är kortare än du tror.
6. Rotera allt som var live i originalet.
7. Skicka den via en kanal som löper ut, inte en som arkiveras för alltid.

Sex minuters arbete mot en legitimationsläcka som annars skulle sitta i biljettkö på obestämd tid.