View Source, kopier nøkkel, eie alt

En sikkerhetsforsker gikk til clickup.com. Åpnet kildekoden. Fant en API-nøkkel hardkodet i JavaScriptet. Kopierte den. Sendte én GET-forespørsel.

Fikk 959 e-postadresser og 3 165 interne funksjonsflagg i retur. Ansatte fra Home Depot. Fortinet. Autodesk. Tenable. Rakuten. Mayo Clinic.

Én streng. Én forespørsel. Alt.

Slik skjer dette

Noen trengte at frontend skulle kalle et API. API-et krevde autentisering. Så la de nøkkelen i JavaScriptet. Ship it, gå videre, neste sprint.

Dette er ikke et avansert angrep. Det er ingen exploit, ingen zero-day, ingen sosial manipulering. Det er view-source: og curl. En nettleser og en terminal. Slikt en nysgjerrig praktikant gjør første dagen.

Nøkkelen hadde ingen scope — den kunne få tilgang til alt API-et eksponerte. Ingen hastighetsgrense — én forespørsel returnerte alt. Ingen utløpsdato — nøkkelen virket til noen la merke til det. Ingen andre faktor — det å ha strengen var den eneste barrieren.

Pengesiden

Folk snakker om dataeksponering. La oss snakke om hva disse dataene er verdt.

959 bedrifts-e-postadresser fra Fortune 500-selskaper. Det er en målliste for spear-phishing som trusselaktører betaler for. Navn, roller, og det faktum at disse selskapene bruker ClickUp — det er den sosiale konteksten som får phishing til å virke.

3 165 interne funksjonsflagg. Det er en veikart. Det forteller konkurrenter hva ClickUp bygger, hva de tester, hva som ligger bak en gate. Det forteller angripere hvilke funksjoner som er halvferdige og trolig sårbare.

Dette er ikke en personvernhendelse. Det er en forretningsinformasjonslekkasje.

Hvorfor dette skjer igjen og igjen

Dette er den fjerde hendelsen med pålogginger i kildekode vi har skrevet om denne måneden. Bitwardens CLI fikk pålogginger høstet fordi de var filer i klartekst. Vercels miljøvariabler kunne dekrypteres fordi «sensitive»-flagget ikke var standard. En utvikler mistet 634 Chrome-passord fordi dekrypteringsnøkkelen lå på samme disk.

Mønsteret er alltid det samme: en pålogging eksisterer som en streng — i en fil, i en variabel, i sidekilde — og noe leser den. Det noe endrer seg. Mønsteret gjør det ikke.

API-nøkler i JavaScript er den mest groteske varianten fordi det ikke kreves noe angrep. Nøkkelen er publisert. Den serveres til hver eneste besøkende. Nettleseren laster den ned, gjengir den, og viser den til alle som høyreklikker.

Hva som burde vært annerledes

API-kallet skulle aldri ha vært autentisert med en statisk nøkkel fra klientsiden. Alternativene:

• Backend-proxy. Frontend kaller din egen backend, som holder nøkkelen serversidig og videresender API-kallet. Nøkkelen når aldri nettleseren.
• Sesjonsomfattede tokens. Frontend får et kortlivet, smalt omfattet token etter autentisering. Det utløper. Det kan bare gjøre det den autentiserte brukeren har lov til. Det er ikke en masternøkkel.
• Ingen nøkkel i det hele tatt. Hvis dataene er offentlige, server dem uten autentisering. Hvis de ikke er offentlige, ikke server dem til ikke-autentisert JavaScript.

Å hardkode en API-nøkkel i klientsidekode er å legge husnøkkelen under dørmatten og publisere adressen din.

Livsløpsproblemet for pålogginger

Denne ClickUp-nøkkelen ble sannsynligvis opprettet én gang, limt inn i en JavaScript-fil, commitet til et repo, deployet til produksjon, og aldri tenkt på igjen. Ingen roterte den. Ingen ga den scope. Ingen satte en utløpsdato. Ingen overvåket hva den fikk tilgang til.

Det er livsløpet for de fleste API-nøkler i de fleste organisasjoner. Opprettet i en fart, limt inn der de trengs, glemt. De hoper seg opp på tvers av kodebaser, konfigurasjonsfiler, CI/CD-pipelines, og tilsynelatende sidekilde — hver og en en dør som aldri låses.

Spørsmålet er ikke om organisasjonen din har en nøkkel som dette. Spørsmålet er hvor mange du har, og om du ville vite det hvis noen kopierte én i dag.