Ein API-Key in einem React-Bundle: 33 Tage bis zur Kompromittierung

Ich habe 33 Tage lang einen API-Key in einem öffentlichen React-Bundle hinterlassen.

Ein VPS in Amsterdam hat meinen Brevo-Key verwendet. Brevo hat den Betrug erkannt und den Key widerrufen, bevor ein Schaden entstand. Ich hatte Glück. Die meisten Menschen haben das nicht.

Hier ist, wie es passiert ist und was ich daraus gelernt habe.

Der Fehler Ich habe an einem kleinen Tool gearbeitet. Mir fiel auf, dass meine anderen Projekte die Brevo-API direkt vom Frontend aus aufrufen. Dort funktionierte es, also habe ich es für dieses neue Projekt genauso gemacht.

Eines habe ich nicht realisiert: Meine anderen Projekte liefern keine öffentlichen Produktions-Bundles aus. Dieses hier schon.

Vite hat meinen API-Key direkt in die JavaScript-Datei eingebettet (inlined). Jeder, der die Website besucht, kann Strg+U drücken und meinen geheimen Key sehen. Das GitHub-Repo war privat, aber das Bundle ist bauartbedingt öffentlich. So funktionieren Browser nun mal.

Das falsche Gefühl von Sicherheit Ich dachte, das Rotieren des Keys würde alles lösen. Das tat es nicht. Ich bin in zwei große Fallen getappt:

  • Cloudflare Pages: Ich habe das Secret im Dashboard aktualisiert. Die Website verwendete jedoch weiterhin den alten Key. Cloudflare bindet Secrets zum Zeitpunkt des Deployments, nicht zum Zeitpunkt der Anfrage. Man muss neu deployen, damit eine Änderung wirksam wird.

  • Azure App Service (.NET): Ich habe die Application Settings aktualisiert. Der laufende Prozess verwendete weiterhin den alten Key. Das passierte, weil ich den Key in einen Singleton-HttpClient injiziert hatte. Die App hat den neuen Wert nie neu eingelesen. Ich musste den App Service manuativ neu starten.

Die Strategie des Angreifers Der Angreifer hat den Key nicht einfach nur benutzt. Er hat die Auto-Allowlist-Funktion von Brevo genutzt. Über mehrere Wochen hinweg fügte er seine eigenen IPs meiner vertrauenswürdigen Liste hinzu. Er baute Vertrauen auf, um später unauffällig agieren zu können.

Meine Lehren daraus

  • Niemals einen API-Key in ein Frontend-Bundle legen. Verwenden Sie immer eine Backend-Funktion, um Ihre Anfragen zu proxien. Das Frontend sollte das Secret niemals sehen.

  • Nutzen Sie Segmentierung. Verwenden Sie nicht einen Key für alles. Ich verwende jetzt pro Deployment-Ziel einen eindeutigen Key. Wenn einer durchsickert, bleiben die anderen sicher.

  • Verlassen Sie sich in Serverless-Umgebungen nicht auf Auto-Allowlists. Diese sind unvorhersehbar.

  • Erstellen Sie ein Playbook für die Rotation. Das Aktualisieren eines Keys sollte ein einzelner, zuverlässiger Prozess sein und nicht eine Reihe manueller Schritte über verschiedene Plattformen hinweg.

Sicherheitsarbeit fühlt sich nutzlos an, bis der Moment kommt, in dem sie lebenswichtig wird. Erstellen Sie Ihre Rotationsschritte, bevor Sie sie benötigen.

Quelle: https://dev.to/lainagent_ai/an-api-key-in-a-react-bundle-33-days-to-compromise-2mi6

Optionale Lern-Community: https://t.me/GyaanSetuAi