it-swarm.com.de

Warum müssen API-Schlüssel privat gehalten werden?

Ich habe in nur einem kleinen Projekt mit öffentlichen APIs gearbeitet, aber ich habe kürzlich erfahren, dass die Verteilung eines Projekts mit API-Schlüsseln ein Sicherheitsrisiko darstellt.

Ich habe also zwei Fragen:

  • Was enthält ein API-Schlüssel, der ein Sicherheitsrisiko darstellt?
  • Wie erstellt man eine Anwendung, die öffentliche APIs verwendet und diese Anwendung verteilt, ohne ein Sicherheitsrisiko darzustellen?

Wenn jemand die Anwendung zurückentwickeln kann, kann er sicherlich alle vorhandenen API-Schlüssel extrahieren.

4
Ethan

Dies hängt davon ab, was der API-Schlüssel tut. Wenn der API-Schlüssel Ihnen jedoch Zugriff auf etwas gewährt oder Ihren Zugriff auf etwas steuert, warum sollten Sie dann möchten, dass andere Personen auf die Ressourcen zurückgreifen, auf die Sie Zugriff haben? Das würdest du nicht.

Denken Sie so darüber nach. Ich besitze einen Dienst und Sie sind ein Benutzer davon, vielleicht sogar ein zahlender Kunde. Ich gebe Ihnen einen API-Schlüssel, der auf einem vereinbarten Servicelevel basiert (möglicherweise API-Aufrufe pro Zeiteinheit). Wenn dieser API-Schlüssel öffentlich wäre, könnten andere Personen ihn verwenden, um sich als Sie auszugeben und Ihre eingeschränkten API-Aufrufe zu verbrauchen.

Das ist wahrscheinlich die am wenigsten besorgniserregende Situation. Das Teilen von API-Schlüsseln wird zu einem größeren Problem, wenn der API-Schlüssel jemanden für den Zugriff auf eine Teilmenge von Daten authentifiziert.

Die Methoden zum Schutz von API-Schlüsseln hängen von der von Ihnen verwendeten Technologie ab. Wenn Sie beispielsweise Web- oder mobile Anwendungen entwickeln, können Sie Ihre API-Schlüssel schützen, indem Sie sicherstellen, dass sie nicht auf dem Client (dem Webbrowser oder dem mobilen Gerät) landen. Stattdessen können sie auf den vom Client verwendeten Servern verbleiben. Der Client kann sich bei den Diensten authentifizieren, die dann entsprechende Anrufe tätigen können. Je nach Umgebung können die API-Schlüssel sogar verschlüsselt werden, da sie in verschiedenen Umgebungen gespeichert sind.

11
Thomas Owens

Es gibt verschiedene Arten von API-Schlüsseln. Einige API-Schlüssel sind so konzipiert, dass sie veröffentlicht werden. Sie werden normalerweise als publizierbare Schlüssel bezeichnet und können an Benutzer in Webseiten oder Anwendungspaketen gesendet werden. Diese Art von API-Schlüsseln dient nicht zur Authentifizierung, sondern zur einfachen Identifizierung. Es gibt nur wenige Anwendungsfälle, in denen dies sinnvoll ist. Im Allgemeinen kann dies jedoch für Anwendungen mit geringer Sicherheit oder für Anwendungen mit geringer Sicherheit in Ordnung sein.

Die meisten API-Schlüssel sind jedoch Authentifizierungsgeheimnisse. Der Wert der Ressource, die geschützt wird, variiert. Selbst wenn die API selbst nur öffentlich verfügbare Daten anzeigt und keine privaten Ressourcen vorhanden sind, muss der API-Anbieter manchmal einen API-Schlüssel verwenden, damit er die Ratenbegrenzung erzwingen kann. Dies ist das Risiko für Sie, wenn Ihr API-Schlüssel durchgesickert ist und jemand Ihre API verwendet hat Der Schlüssel ist, dass Ihrer Anwendung der Dienst möglicherweise effektiv verweigert wird, weil Sie Ihr festgelegtes Limit erreicht haben. Wenn es sich um eine kostenpflichtige API handelt, können unnötige Kosten entstehen, wenn andere Ihren API-Schlüssel verwenden.

In anderen Fällen ist der API-Schlüssel als Token für Ihre Autorisierung gedacht, dass die Anforderung vom Dienstanbieter ausgeführt werden soll. Wenn Sie Ihren API-Schlüssel verlieren, haben Sie nicht mehr die Kontrolle über die geschützte Ressource, da Ihr Benutzer den Archivanbieter direkt unter Umgehung Ihrer beabsichtigten Geschäftslogik anweisen kann.

7
Lie Ryan

Denken Sie so darüber nach, die meisten Menschen haben nicht die Angewohnheit, Schlüssel für ihr Privateigentum (Haus, Autos usw.) zu verteilen. Warum? Weil diese Schlüssel kritische Assets schützen und verhindern, dass Personen, die Sie nicht kennen, Dinge stehlen. Sie können sich vorstellen der API-Schlüssel als API-Passwort. Alles, was Ihre Anwendung mit der API tun darf, kann jemand anderes tun, wenn er Ihre Anmeldeinformationen stiehlt.

Das Konzept ist für digitale Schlüssel nicht anders. Die einzige Herausforderung besteht darin, dass es schwieriger ist, sie zu sichern oder die Schlüssel sicher zu handhaben. Es ist auch üblicher, separate Schlüssel für jeden Client der API bereitzustellen. Dies ermöglicht nicht nur die Verwaltung verschiedener Abonnementstufen oder Berechtigungssätze für jeden Client, sondern auch autorisierende Überwachungsprotokolle, bei denen der Inhaber der API-Schlüssel die protokollierten Aktionen nicht ablehnen kann .

Wenn es sich um OAuth 2, den am häufigsten verwendeten API-Zugriffskontrollmechanismus, handelt), gibt es zwei Schlüssel, über die Sie sich Sorgen machen müssen:

  • Der Client-Schlüssel: Identifiziert Ihre Anwendung gegenüber dem API-Anbieter
  • Der geheime Schlüssel: Authentifiziert Sie, damit sich niemand als Sie ausgeben kann

Die Kombination von Schlüsseln ist kritisch, weshalb OAuth TLS für den Austausch der Schlüssel vorschreibt. Der Client-Schlüssel selbst ist weniger kritisch gegenüber einer zu schützenden Ressource, sollte jedoch nicht angekündigt werden Der geheime Schlüssel ist derjenige, für den Sie zusätzliche Schutzmaßnahmen ergreifen müssen.

Unter dem Strich sollte jeder Schlüssel sorgfältig geschützt werden. Es gibt genug Leute da draußen, die Sicherheitslücken missbrauchen wollen, um das zu bekommen, was sie wollen. Selbst kleine unbedeutende Websites sind gute Ziele, wenn sie dort etwas finden, mit dem sie sich an anderer Stelle als Benutzer ausgeben können.


Was Ihre zweite Frage betrifft, gibt es einen Grund, warum OAuth 2 zu einem Industriestandard geworden ist. Es ist gut definiert und es gibt unterstützende Bibliotheken in nahezu jeder Programmiersprache, um damit zu arbeiten. Es ist am besten das Rad nicht ohne guten Grund neu zu erfinden, besonders wenn es so viel Unterstützung für den bestehenden Standard gibt.

Bitte beachten Sie: Beim Reverse Engineering der Logik der Anwendung wird nicht automatisch Zugriff auf die von ihr verwalteten Daten gewährt. Wenn Sie Ihre Anwendung korrekt gestalten, verfügen Sie nicht unbedingt über die erforderlichen Informationen, um die Schlüssel anderer Personen zu stehlen.

6
Berin Loritsch

Ich habe in nur einem kleinen Projekt mit öffentlichen APIs gearbeitet, aber ich habe kürzlich erfahren, dass die Verteilung eines Projekts mit API-Schlüsseln ein Sicherheitsrisiko darstellt.

Im Ernst, ich möchte Ihnen gratulieren, dass Sie dies bereits so früh in Ihrer Karriere wissen, denn ob Sie es glauben oder nicht, viele leitende Entwickler sind immer noch falsch informiert oder wissen nichts über die Auswirkungen auf die Sicherheit bei der Verteilung eines API-Schlüssels.

Eine der Hauptursachen, die zu all dieser Verwirrung über API-Schlüssel führt, die viele gar nicht bemerken, ist, dass ein Entwickler sich des Unterschieds zwischen [~ # ~] was [~ # ~] bewusst sein muss ] und [~ # ~] wer [~ # ~] auf den API-Server zugreift.

Der Unterschied zwischen WHO und WHAT besteht darin, auf den API-Server zuzugreifen

Um die Unterschiede zwischen dem [~ # ~] wer [~ # ~] und dem [~ # ~] was [~ # ~] besser zu verstehen ) auf einen API-Server zugreifen, verwenden wir dieses Bild:

Man in the Middle Attack

Der beabsichtigte Kommunikationskanal stellt die mobile App dar, die wie erwartet von einem legitimen Benutzer ohne böswillige Absichten verwendet wird, eine nicht manipulierte Version der mobilen App verwendet und direkt mit dem API-Server kommuniziert, ohne dass ein Mann in der Mitte angegriffen wird.

Der tatsächliche Kanal kann verschiedene Szenarien darstellen, z. B. einen legitimen Benutzer mit böswilligen Absichten, der möglicherweise eine neu gepackte Version der mobilen App verwendet, einen Hacker, der die Originalversion der mobilen App verwendet, während ein Mann in der Mitte sie angreift, um zu verstehen, wie Die Kommunikation zwischen der mobilen App und dem API-Server erfolgt, um Angriffe auf Ihre API automatisieren zu können. Viele andere Szenarien sind möglich, aber wir werden hier nicht jedes einzelne aufzählen.

Ich hoffe, dass Sie jetzt bereits eine Ahnung haben, warum die [~ # ~] wer [~ # ~] und die [~ # ~] was [~ # ~] sind nicht dasselbe, aber wenn nicht, wird es gleich klar.

Der [~ # ~], der [~ # ~] der Benutzer der mobilen App ist, die wir auf verschiedene Arten authentifizieren, autorisieren und identifizieren können, z. B. mithilfe von OpenID Connect- oder OAUTH2-Flows.

OAUTH

Im Allgemeinen bietet OAuth Clients im Auftrag eines Ressourcenbesitzers einen "sicheren delegierten Zugriff" auf Serverressourcen). Es gibt einen Prozess an, mit dem Ressourcenbesitzer den Zugriff von Drittanbietern auf ihre Serverressourcen ohne Freigabe autorisieren können Ihre Anmeldeinformationen. Speziell für die Verwendung mit HTTP (Hypertext Transfer Protocol) entwickelt, ermöglicht OAuth) im Wesentlichen die Ausgabe von Zugriffstoken an Drittanbieter-Clients durch einen Autorisierungsserver mit Genehmigung des Ressourcenbesitzers. Der Dritte verwendet dann das Zugriffstoken, um auf die geschützten Ressourcen zuzugreifen, die vom Ressourcenserver gehostet werden.

OpenID Connect

OpenID Connect 1.0 ist eine einfache Identitätsschicht über dem Protokoll OAuth 2.0). Es ermöglicht Clients, die Identität des Endbenutzers anhand der von einem Autorisierungsserver durchgeführten Authentifizierung zu überprüfen um grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise zu erhalten.

Während die Benutzerauthentifizierung den API-Server möglicherweise darüber informiert [~ # ~], wer [~ # ~] die API verwendet, kann nicht garantiert werden, dass die Anforderungen von [stammen ~ # ~] was [~ # ~] Sie erwarten, die Originalversion der mobilen App.

Jetzt brauchen wir eine Möglichkeit, um [~ # ~] zu identifizieren, was [~ # ~] den API-Server aufruft, und hier werden die Dinge schwieriger, als die meisten Entwickler vielleicht denken. Das [~ # ~] was [~ # ~] ist das Ding, das die Anfrage an den API-Server sendet. Ist es wirklich eine echte Instanz der mobilen App oder ist ein Bot, ein automatisiertes Skript oder ein Angreifer, der mit einem Tool wie Postman manuell mit dem API-Server herumstochert?

Zu Ihrer Überraschung stellen Sie möglicherweise fest, dass es sich um einen der legitimen Benutzer handelt, die eine neu gepackte Version der mobilen App oder ein automatisiertes Skript verwenden, das versucht, den von der Anwendung bereitgestellten Dienst zu spielen und zu nutzen.

Um herauszufinden, was [~ # ~] was [~ # ~] ist, greifen Entwickler in der Regel auf einen API-Schlüssel zurück, den sie normalerweise im Code ihrer mobilen App fest codieren. Einige Entwickler gehen noch einen Schritt weiter und berechnen den Schlüssel zur Laufzeit in der mobilen App. Daher wird er zu einem Laufzeitgeheimnis, im Gegensatz zum früheren Ansatz, wenn ein statisches Geheimnis in den Code eingebettet ist.

Der obige Artikel wurde aus einem Artikel mit dem Titel WARUM BRAUCHT IHRE MOBILE APP EINEN API-SCHLÜSSEL ? extrahiert, den Sie vollständig lesen können hier , Dies ist der erste Artikel in einer Reihe von Artikeln über API-Schlüssel.

Reverse Engineering

Wenn jemand die Anwendung zurückentwickeln kann, kann er sicherlich alle vorhandenen API-Schlüssel extrahieren.

Jedes Geheimnis, das in einer Webanwendung gespeichert ist, lässt sich leicht extrahieren. Drücken Sie einfach F12 im Browser oder view page source und dann danach suchen.

Für eine mobile App denken einige vielleicht, dass dies viel schwieriger ist, aber in der Tat auch einfach, und Sie können den Weg des Reverse Engineerings der mobilen apk einschlagen, wie ich in diesem Artikel zeige So extrahieren Sie eine API-Schlüssel aus einer mobilen App mit statischer Binäranalyse:

Durch die Verwendung von MobSF zum Reverse Engineering einer APK für eine mobile App können wir schnell einen API-Schlüssel extrahieren und erhalten eine große Menge an Informationen, mit denen wir weitere Analysen durchführen können, die möglicherweise mehr Angriffsvektoren in die mobile App und den API-Server aufdecken. Es ist nicht ungewöhnlich, unter diesen Informationen oder im dekompilierten Quellcode, der in den Formaten smali und Java) heruntergeladen werden kann, auch Geheimnisse für den Zugriff auf Dienste von Drittanbietern zu finden.

Meine bevorzugte Methode zum Extrahieren eines API-Schlüssels ist jedoch ein MitM-Angriff, bei dem ich den Datenverkehr zwischen der mobilen App und dem API-Server über das Open Source-Tool mitmproxy als Proxy übertragen möchte Mach es in einer mobilen App zu diesem Artikel, den ich geschrieben habe Stiehl diesen API-Schlüssel mit einem Mann im mittleren Angriff:

Wir können zwar fortgeschrittene Techniken wie JNI/NDK verwenden, um den API-Schlüssel im Code der mobilen App zu verbergen, aber es hindert niemanden daran, einen MitM-Angriff auszuführen, um den API-Schlüssel zu stehlen. Tatsächlich ist ein MitM-Angriff so einfach, dass er sogar von Nicht-Entwicklern ausgeführt werden kann.

DEINE FRAGEN

Frage 1

Was enthält ein API-Schlüssel, der ein Sicherheitsrisiko darstellt?

Meistens geht es dann nicht darum, was es enthält, sondern was es darstellt, und vielleicht verstehen Sie bereits, dass es verwendet werden sollte, um [~ # ~] was [~ # ~] zu identifizieren ) stellt eine Verbindung zu Ihrem API-Server her.

In den Fällen, in denen ein API-Schlüssel ein JWT-Token ist, kann er vertrauliche Informationen enthalten oder nicht.

JSON Web Token (JWT) ist ein offener Standard (RFC 7519), der eine kompakte und in sich geschlossene Methode zur sicheren Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert. Diese Informationen können überprüft und als vertrauenswürdig eingestuft werden, da sie digital signiert sind. JWTs können mit einem geheimen (mit dem HMAC-Algorithmus) oder einem öffentlichen/privaten Schlüsselpaar mit RSA oder ECDSA signiert werden.

Selbst wenn die API-Schlüssel keine vertraulichen Daten enthalten, stellen sie ab dem Moment, in dem sie zum Schutz des Zugriffs auf Ressourcen verwendet werden, ein Sicherheitsrisiko dar, da sie einfach aus Clientanwendungen extrahiert und für automatisierte Angriffe wiederverwendet werden können Der Angreifer kann sich als API-Server als echte Anwendung (WHAT) und echter Benutzer (WHO) ausgeben.

Frage 2

Wie erstellt man eine Anwendung, die öffentliche APIs verwendet und diese Anwendung verteilt, ohne ein Sicherheitsrisiko darzustellen?

Die wahre Wahrheit ... Sie können dies nicht in einer Web-App tun, da nach der Veröffentlichung jedes vertrauliche Datum Teil der Public Domain wird und von jedem angezeigt werden kann, der die Web-App mit der erstellten App überprüft -in Browser-Entwicklertools.

In einer mobilen App haben Sie möglicherweise eine mögliche Lösung, die von Mobile App Attestation bekannt ist.

Mobile App Attestation erklärt

Die Rolle einer Mobile App Attestation-Lösung besteht darin, zur Laufzeit sicherzustellen, dass Ihre mobile App nicht manipuliert wurde, nicht auf einem gerooteten Gerät ausgeführt wird, nicht von einem Framework wie xPosed oder Frida instrumentiert wird und nicht von MitM angegriffen wird wird durch Ausführen eines SDK im Hintergrund erreicht. Der in der Cloud ausgeführte Dienst fordert die App heraus und bestätigt anhand der Antworten die Integrität der mobilen App und des Geräts, auf dem das Gerät ausgeführt wird. Daher ist das SDK niemals für Entscheidungen verantwortlich.

Frida

Fügen Sie Ihre eigenen Skripte in Black-Box-Prozesse ein. Haken Sie jede Funktion ein, spionieren Sie Krypto-APIs aus oder verfolgen Sie den Code einer privaten Anwendung, ohne dass ein Quellcode erforderlich ist. Bearbeiten Sie, klicken Sie auf Speichern und sehen Sie sofort die Ergebnisse. Alles ohne Kompilierungsschritte oder Programmneustarts.

xPosed

Xposed ist ein Framework für Module, die das Verhalten des Systems und der Apps ändern können, ohne APKs zu berühren. Das ist großartig, weil es bedeutet, dass Module für verschiedene Versionen und sogar ROMs ohne Änderungen arbeiten können (solange der ursprüngliche Code nicht zu stark geändert wurde). Es ist auch leicht rückgängig zu machen.

MiTM-Proxy

Ein interaktiver TLS-fähiger Intercepting-HTTP-Proxy für Penetrationstester und Softwareentwickler.

Bei erfolgreicher Bestätigung der Integrität der mobilen App wird ein kurzlebiges JWT-Token ausgestellt und mit einem Geheimnis signiert, das nur dem API-Server und dem Dienst zur Bestätigung der mobilen App in der Cloud bekannt ist. Im Falle eines Fehlers bei der Bestätigung der mobilen App wird das JWT-Token mit einem Geheimnis signiert, das der API-Server nicht kennt.

Jetzt muss die App bei jedem API-Aufruf das JWT-Token in den Headern der Anfrage senden. Auf diese Weise kann der API-Server Anforderungen nur dann bearbeiten, wenn er die Signatur und die Ablaufzeit im JWT-Token überprüfen und ablehnen kann, wenn die Überprüfung fehlschlägt.

Sobald das vom Mobile App Attestation-Dienst verwendete Geheimnis der mobilen App nicht bekannt ist, kann es zur Laufzeit nicht zurückentwickelt werden, selbst wenn die App manipuliert wird, auf einem gerooteten Gerät ausgeführt wird oder über eine Verbindung kommuniziert, bei der es sich um die handelt Ziel eines Mannes im mittleren Angriff.

Der Mobile App Attestation-Dienst existiert bereits als SAAS-Lösung bei Approov (ich arbeite hier) und bietet SDKs für verschiedene Plattformen, einschließlich iOS, Android, React Native und andere. Für die Integration ist außerdem eine erforderlich Kleine Überprüfung des API-Servercodes, um das vom Cloud-Dienst ausgegebene JWT-Token zu überprüfen. Diese Überprüfung ist erforderlich, damit der API-Server entscheiden kann, welche Anforderungen zu bedienen und welche abzulehnen sind.

FAZIT

Ich bin ein frischgebackener Informatiker, daher wäre eine Erklärung dafür sehr dankbar.

Ich hoffe, dass ich Ihre Fragen auf einfache Weise beantworten konnte und dass Sie jetzt den Unterschied zwischen [~ # ~] was [~ # ~] und [~ # ~] wer [~ # ~] auf Ihren API-Server zugreift, da Sie durch das Aufrechterhalten dieses Begriffs in Ihrem Speicher viel sichereren Code schreiben können, unabhängig davon, ob es sich um ein Back-End oder einen Client handelt Seitencode.

Für Web-Apps können Sie sie daher nicht in einem Format verteilen, das den API-Schlüssel sicher hält. Daher müssen Sie Ihre Sicherheitsanstrengungen auf den API-Server konzentrieren.

Für mobile Apps besteht weiterhin Hoffnung in Form einer Mobile App Attestation-Lösung, die sowohl die mobile App als auch den API-Server schützt und sich nicht mit Fehlalarmen befassen muss.

Letztendlich muss die Lösung zum Schutz Ihrer Anwendung und Ihres API-Servers entsprechend dem Wert dessen, was Sie schützen möchten, und den gesetzlichen Anforderungen für diese Art von Daten wie den GDPR-Bestimmungen in Europa ausgewählt werden.

MÖCHTEN SIE DIE EXTRA MILE GEHEN?

OWASP Mobile Security Project - Top 10 Risiken

Das OWASP Mobile Security Project ist eine zentralisierte Ressource, mit der Entwickler und Sicherheitsteams die Ressourcen erhalten, die sie zum Erstellen und Verwalten sicherer mobiler Anwendungen benötigen. Im Rahmen des Projekts ist es unser Ziel, mobile Sicherheitsrisiken zu klassifizieren und Entwicklungskontrollen bereitzustellen, um deren Auswirkungen oder die Wahrscheinlichkeit der Nutzung zu verringern.

1
Exadra37