Geheimnisse, die mit dem Bündel reisen: Millionen von Apps setzen Token im Browser aus und wie es zu stoppen

API-Schlüssel und Tokens Lecks waren nicht mehr eine Seltenheit. In den letzten Jahren haben wir gesehen, wie Geheimnisse, die in geschlossenen Umgebungen bleiben sollten, in öffentlichen Repositorien, Container-Bildern und in zunehmendem Maße innerhalb des eigenen Codes zirkulieren, der an den Browser gesendet wird. Warum treten diese Lecks weiterhin auf, wenn es so viele Werkzeuge und Praktiken gibt, um sie zu vermeiden? Nach der Untersuchung, wie die verschiedenen Ansätze zur Erkennung von Geheimnissen funktionieren und eine spezifische Überprüfung für JavaScript-Bündel entwickelt, war das Ergebnis überraschend: die Analyse von Millionen von Anwendungen fand zehntausende von Token exponiert, viele von ihnen aktiv und mit mächtigen Berechtigungen.

Klassische Methoden für die Suche nach Geheimnissen basieren oft auf zwei Säulen: das Kennen von gemeinsamen Routen, in denen Anmeldeinformationen hinterlassen werden können und Muster (in der Regel regelmäßige Ausdrücke) anwenden, die bekannte Tokenformate identifizieren. Diese vollautomatische Technik liefert nützliche und schnelle Ergebnisse und ist diejenige, die viele Infrastrukturscanner verwenden. Allerdings hat es eine offensichtliche Grenze: wenn die Suchmaschine entspricht, um nach der Wurzelseite einer Domain zu fragen und nicht die Anforderungen, die ein Browser macht - wie zum Beispiel das Herunterladen von JavaScript-Dateien - viele Geheimnisse nie vor dem Detektor gehen. Ein echtes Beispiel für Vorlage nach diesem Muster kann in ProjectDiscovery Repositories für Nuclei gesehen werden, wo Überprüfungen beschrieben werden, dass direkte Antworten auf bestimmte HTTP-Anforderungen inspizieren und entsprechend handeln: Nuclei Vorlage für GitLab persönliche Token.

Andererseits scheinen dynamische Sicherheitstests (DAST) theoretisch eine gute Option zur Erkennung von Geheimnissen am Frontend, weil sie die eigentliche Navigation nachempfunden, die Anwendung nachverfolgen und Ströme verstehen können, die eine Authentifizierung erfordern. In der Praxis ist der Betrieb von DAST in umfassender Weise teurer und erfordert fortschrittliche Konfiguration, so dass viele Organisationen es auf eine begrenzte Anzahl von kritischen Anwendungen reservieren. Darüber hinaus enthalten nicht alle DAST-Scanner die gleiche Auswahl an Detektionsmustern wie auf die Suche nach Geheimnissen spezialisierte Werkzeuge.

Statische Code-Verifikation (SAST) ist ein weiteres Element des Arsenals: es analysiert den Quellcode, um zu verhindern, dass Geheimnisse in die Produktion kommen und ist in vielen Szenarien sehr effektiv. Doch JavaScript-Bündel, die in modernen Webanwendungen verwendet werden, insbesondere in den Single-Page Applications (SPA), können in Stufen nach statischer Analyse oder mit Bauprozessen gebaut werden, die Variablen injizieren. Damit können neue Geheimnisse in kompilierten Artefakten auftreten, ohne die Steuerungen mit SAST durchlaufen zu lassen, so dass eine rein statische Analyse des Repository nicht immer erkennt, was letztendlich dem Kunden dient.

Mit diesen Einschränkungen wurde eine Überprüfung entworfen, um die JavaScript-Bündel zu untersuchen, die von einem Browser heruntergeladen werden können. Es wurde auf einer Skala gearbeitet: ca. fünf Millionen Anwendungen wurden auf der Suche nach Tokenmustern in den Dateien, die dem Client diente verfolgt. Der Umschlag der Ergebnisse überstieg 100 MB Text und veröffentlichte mehr als 42.000 passende Anmeldeinformationen mit 334 verschiedenen Arten von Geheimnissen. Nicht alle Befunde wurden manuell verdreifacht, aber unter den verifizierten Proben schienen hochimpact Belichtungen das Problem gut zu illustrieren.

Unter den schwersten Fällen wurden Token für Code-Repository-Plattformen entdeckt. Insgesamt wurden 688 Token mit Dienstleistungen wie GitHub und GitLab verknüpft, und ein relevanter Teil blieb in Kraft und ermöglichte den Zugang zu privaten Repositorien. In einem bestimmten Fall befand sich ein GitLab-Personaltoken in einer JavaScript-Datei, die umfangreiche Organisationsgenehmigungen, einschließlich Pipeline-Geheimnisse und Zugriff, die Nebenbewegungen zu Dienstleistungen wie AWS oder SSH-Zugang erleichtern. Die offizielle persönliche Tokendokumentation von GitLab ist ein guter Bezugspunkt für das Verständnis der Risiken, die sie aussetzen: GitLab - Persönlicher Zugriff auf Tokens. Ebenso unterhält GitHub Leitlinien für die Erstellung und Verwaltung von Token, die bekannt sein sollten: GitHub - Persönlicher Zugriff auf Tokens.

Eine weitere bemerkenswerte Exposition betroffenen API-Schlüssel für Projektmanagement-Tools. Lineare Token befanden sich in Front-End-Code-Einsätzen, mit denen Sie Tickets, interne Projekte und Links zu Integrationen lesen konnten, die wiederum Zugang zu anderen Vermögenswerten und Dienstleistungen bieten konnten. Über diese Beispiele hinaus, der Scan gefunden Anmeldeinformationen im Zusammenhang mit APIs der computergestützten Design-Software, Link kürzere mit der Fähigkeit, URLs, E-Mail-Marketing-Plattformen mit Zugriff auf Listen und Kampagnen, Chat- und Automatisierungsplattformen Webbooks - einschließlich Hunderte von aktiven Endpoints von Slack, Microsoft Teams, Discord und Zapier -, PDF-Konverter und kommerzielle Intelligenz-Tools, die exponierte Kontakt-Datenbanken. Diese Ergebnisse bestätigen, dass der Risikobereich nicht auf wenige Lieferanten beschränkt ist, sondern eine breite Palette von Integrationen und Dienstleistungen umfasst.

Welche praktischen Lehren ergeben sich daraus? Zunächst bleiben die Maßnahmen von "links" - um die frühen Entwicklungsstadien zu analysieren und zu verhindern - grundlegend. SAST-Tools, Repository-Scanner und IDE-Plugins erkennen viele schlechte Praktiken, bevor der Code die Entwicklungsumgebung verlässt. Sie reichen jedoch nicht allein aus: jedes Geheimnis, das in Build-Phasen oder während der Bereitstellungskonfiguration eingeführt wird, kann diese Steuerungen vermeiden und in einem Bündel verpackt werden, das dem Browser dient.

Es ist daher wichtig, Kontrollen zu integrieren, die das reale Verhalten eines Web-Clients reproduzieren: Herunterladen der JS-Dateien, die die Anwendung liefert, inspizieren sie auf der Suche nach Tokenmustern und validieren Sie die Aktivität der erfassten Anmeldeinformationen. Dieser Ansatz erfordert Mechanismen, die den gleichen Ressourcenbaum interpretieren, den ein Browser beim Laden eines SPA erhält und auch automatisierte Überprüfungen durchführt, um festzustellen, ob ein Token gültig bleibt. Die Sicherheitsgemeinschaft und die guten Praxisführer enthalten Empfehlungen zur Verwaltung von Geheimnissen - zum Beispiel OWASP Geheimverwaltung Cheat Sheet- dass es angemessen ist, mit Erkennungen in der Zeit der Ausführung zu integrieren.

Was die gezielte Minderung betrifft, sollten Organisationen soweit wie möglich verhindern, dass ein Anmeldeschluss mit sensiblen Genehmigungen den Kunden erreicht. Stattdessen sollten Anwendungen Anrufe an Dienste auf kontrollierten Servern delegieren, Key-hiding-Proxys verwenden, kurzlebige Token verwenden und das Prinzip des kleinen Privilegs anwenden. Darüber hinaus hilft die Aktivierung und Ergänzung des Scannens von Geheimnissen, die von Lieferanten wie GitHub angeboten werden - siehe Ihren geheimen Erkennungsdienst -, Lecks im Code und veröffentlichte Artefakte abzufangen: GitHub - Secret Scannen.

Das Bild entwickelt sich auch durch die zunehmende Automatisierung und den Einsatz von Code, der von IA-Werkzeugen erzeugt wird: Werden automatisierte Pipelines nicht zum Schutz von Geheimnissen konfiguriert, erhöht sich das Risiko, Anmeldeinformationen in kompilierte Artefakte einzubringen. Die Lösung besteht darin, statische Überprüfungen im Entwicklungsfluss, Repository-Scans, Steuerungen während der Compilation und dynamischen Erkennung zu kombinieren, die den Download und die Inspektion der Pakete simulieren, die den Browser erreichen. Speziell für SPA-Anwendungen beinhaltet dies die Einbeziehung von Spinnen und Herunterladen statischer Ressourcen als Teil des Sicherheitsprozesses, anstatt nur für die Homepage zu fragen.

Das Erkennen und Entfernen von exponierten Geheimnissen in Bündeln ist keine triviale Aufgabe, aber die Beweise zeigen, dass es wesentlich ist: wenn Millionen von Anwendungen analysiert wurden, erschienen Zehntausende von exponierten Token und Hunderte von verschiedenen Arten von Geheimnissen. Adoptieren Sie eine Mehrschicht-Strategie, aktualisieren Sie CI / CD-Prozesse, um zu vermeiden, Anmeldeinformationen in öffentliche Artefakte zu injizieren, und führen Sie Scans, die das eigentliche Browser-Erlebnis replizieren sind notwendige Schritte, um dieses Risiko signifikant zu reduzieren. Wenn Sie die Unterschiede zwischen statischer und dynamischer Analyse vertiefen und besser verstehen wollen, wenn Sie jede Technik verwenden, sind die Ressourcen von OWASP zur Sicherheitsanalyse ein guter Ausgangspunkt: OWASP - Quellcode-Analyse und OWASP - Dynamische Analyse.

Kurz gesagt, das Problem ist klar: Geheimnisse sollten nicht in den Browser reisen, sondern mit aktuellen Gebäude-, Bereitstellungs- und Automatisierungsprozessen, die weiterhin passieren. Die Antwort ist kein einziges Werkzeug, sondern eine Kombination aus bewährter Praxis, Pipelinesteuerungen und Erkennung, die genau untersucht, was der Browser herunterlädt. Nur auf diese Weise können wir die Wahrscheinlichkeit reduzieren, dass ein engagierter Token das Tor zu viel wertvolleren Vermögenswerten sein wird.