Visa källkod, kopiera nyckeln, äg allt

En säkerhetsforskare gick till clickup.com. Öppnade sidans källkod. Hittade en API-nyckel hårdkodad i JavaScript-koden. Kopierade den. Skickade en GET-förfrågan.

Fick tillbaka 959 e-postadresser och 3 165 interna funktionsflaggor. Anställda på Home Depot. Fortinet. Autodesk. Tenable. Rakuten. Mayo Clinic.

En sträng. En förfrågan. Allt.

Så här händer det

Någon behövde att frontend anropade ett API. API:t krävde autentisering. Så de la nyckeln i JavaScript-koden. Skicka iväg det, gå vidare, nästa sprint.

Det här är inget avancerat angrepp. Ingen exploit, ingen zero-day, ingen social engineering. Det är view-source: och curl. En webbläsare och en terminal. Sånt som en nyfiken praktikant gör första dagen.

Nyckeln hade inget scope — den kunde komma åt allt som API:t exponerade. Ingen rate limit — en förfrågan returnerade allt. Inget utgångsdatum — nyckeln fungerade tills någon upptäckte den. Ingen andra faktor — att ha strängen var det enda skyddet.

Pengavinkeln

Folk pratar om exponerade data. Låt oss prata om vad de här uppgifterna är värda.

959 företagsadresser från Fortune 500-bolag. Det är en mållista för spear phishing som aktörer betalar för. Namn, roller och det faktum att de här bolagen använder ClickUp — det är det sociala sammanhang som gör att phishing fungerar.

3 165 interna funktionsflaggor. Det är en roadmap. Den berättar för konkurrenter vad ClickUp bygger, vad de testar, vad som ligger bakom en grind. Den berättar för angripare vilka funktioner som är halvfärdiga och sannolikt sårbara.

Det här är ingen integritetsincident. Det är en affärsstrategisk läcka.

Varför det här händer igen och igen

Det här är den fjärde incidenten med uppgifter i källkoden som vi skrivit om den här månaden. Bitwardens CLI fick sina uppgifter hämtade eftersom de låg i klartextfiler. Vercels miljövariabler gick att dekryptera eftersom flaggan "sensitive" inte var standard. En utvecklare förlorade 634 Chrome-lösenord eftersom dekrypteringsnyckeln låg på samma disk.

Mönstret är alltid detsamma: en uppgift finns som en sträng — i en fil, i en variabel, i sidans källkod — och något läser den. Det något förändras. Mönstret gör det inte.

API-nycklar i JavaScript är den värsta varianten eftersom inget angrepp krävs. Nyckeln är publicerad. Den serveras till varje besökare. Webbläsaren laddar ner den, renderar den och visar den för vem som helst som högerklickar.

Vad som borde varit annorlunda

API-anropet borde aldrig ha autentiserats med en statisk nyckel från klientsidan. Alternativen:

• Backend-proxy. Frontend anropar din egen backend, som håller nyckeln serversidigt och vidarebefordrar API-anropet. Nyckeln når aldrig webbläsaren.
• Sessionsbegränsade tokens. Frontend får en kortlivad, smalt avgränsad token efter autentisering. Den löper ut. Den kan bara göra det den autentiserade användaren har rätt att göra. Den är ingen master-nyckel.
• Ingen nyckel alls. Om uppgifterna är publika, servera dem utan autentisering. Om de inte är publika, servera dem inte till oautentiserad JavaScript.

Att hårdkoda en API-nyckel i kod som körs på klienten är att lägga husnyckeln under dörrmattan och publicera adressen.

Livscykelproblemet

Den här ClickUp-nyckeln skapades troligen en gång, klistrades in i en JavaScript-fil, committades till ett repo, rullades ut i produktion och tänktes aldrig på igen. Ingen roterade den. Ingen begränsade den. Ingen satte ett utgångsdatum. Ingen övervakade vad den kom åt.

Det är livscykeln för de flesta API-nycklar i de flesta organisationer. Skapade i all hast, inklistrade där de behövs, glömda. De ansamlas i kodbaser, konfigurationsfiler, CI/CD-pipelines och tydligen i sidans källkod — var och en en dörr som aldrig låses.

Frågan är inte om din organisation har en nyckel som den här. Frågan är hur många ni har, och om du skulle märka om någon kopierade en idag.