Base64 sikkerhed: hvad kodning beskytter og ikke beskytter

Adskil reversibel kodning fra kryptering, signaturer og validering, og håndter afkodede dokumenter uden at udføre dem.

Base64 giver ikke hemmeligholdelse. Enhver, der modtager den kodede værdi, kan gendanne dens bytes uden adgangskode eller nøgle. At skjule legitimationsoplysninger i en lang streng ændrer deres udseende, ikke hvem der kan læse dem. Anvend de samme håndteringsregler på kodede hemmeligheder som på originalerne.

Kodning, kryptering og signaturer besvarer forskellige spørgsmål

Kodning spørger, hvordan bytes kan rejse gennem et tekstorienteret system. Kryptering beskytter fortroligheden under en kryptografisk nøgle. Et autentificeringsmærke eller digital signatur kan fastslå, at data er produceret af en autoriseret part og ikke er blevet ændret, forudsat at verifikationsprocessen og nøglerne er korrekte. En almindelig kontrolsum hjælper hovedsageligt med at opdage utilsigtet korruption. Ingen af ​​disse garantier følger af Base64 alene.

En afkodet JWT er et nyttigt eksempel. Dens overskrift og nyttelast er læsbare strukturer, men læsning af dem bekræfter ikke signatur-, udsteder-, publikums- eller udløbspolitikken. Behandl et ubekræftet krav som ikke-pålideligt input. Lad ikke en seers formaterede JSON blive en godkendelsesbeslutning.

Hold afkodet indhold inaktivt

En nyttelast kan afkode til HTML, JavaScript, en SVG indeholdende aktivt indhold eller et forkert udformet dokument. Vis tekst med textContent, ikke innerHTML. Kør ikke afkodet kode eller indsæt en vilkårlig SVG på din side. En erklæret datatype URI MIME leveres af afsenderen og kan være falsk. Filsignaturer hjælper med at identificere et sandsynligt format, men en matchende overskrift fastslår ikke, at en fil er komplet eller sikker.

// decodedText comes from an untrusted payload.
const output = document.createElement('pre');
output.textContent = decodedText;
document.body.append(output); // displays markup as text

Indstil grænser før tildeling af hukommelse

Kodet tekst udvider data, og en browser kan indeholde inputstrengen, dekodede bytes og forhåndsvisningen på samme tid. Håndhæv grænser før afkodning, begræns accepterede dokumenttyper, og lad brugere annullere lange operationer. Forkert input bør producere en separat fejltilstand i stedet for et output, der kan kopieres, som om det var vellykkede data.

Ved følsomt arbejde skal du inspicere værktøjets netværksadfærd og fastholdelsespolitik. Browserbehandling og server API behandling har forskellige grænser. Undgå at sætte tokens i side-URL'er, hvor de kan indtaste browserhistorik, skærmbilleder eller adgangslogfiler. Når du tester, skal du bruge syntetiske data med samme struktur. RFC 4648 diskuterer kodningsuklarheder; sikkerheden af ​​en større protokol afhænger stadig af dens komplette design.