shipfast api protection
vor, improvments, fixes and security updates
Willkommen! Dieses Repository ist Teil dieser Reihe von Blog -Posts zu praktischen API -Sicherheitstechniken. Die Serie führt Sie durch den Prozess der Verteidigung eines mobilen API -Backends gegen verschiedene Exploits, mit denen ein Angreifer möglicherweise Zugriff auf die von ihm gehaltenen Daten erhält. In diesem Demonstrationsszenario ermöglicht der Angriff den realen Nutzern des Systems, auf Kosten des Unternehmens einen unfairen Geschäftsvorteil zu erzielen.
Dieses Repository enthält alle drei Komponenten, die zur Beschreibung der Schiffsstory verwendet werden:
Wir haben alle 3 Projekte im selben Repository aufbewahrt und den Code so strukturiert, dass alle Schritte aus der Fortschritts der Blogserien enthalten sind. Wir hoffen, dass dies das gesamte Verständnis erleichtert.
Nach dem Einstellen der Szene im ersten Blog -Beitrag zeigen aufeinanderfolgende Einträge, wie Sicherheitsmaßnahmen gegebenenfalls gestärkt (oder umgangen) werden können, indem sie Links zum Code in diesem Github -Repository unter Verwendung von Links ausgehen. Die Blog -Serie kann zusammengefasst werden, indem sich auf die wichtigste Sicherheitsmethode in jedem einzelnen bezieht:
Wir bieten frei verfügbare Bereitstellungen der beiden Dienste und APKs, die Sie herunterladen und installieren können, sodass Sie mit ihnen arbeiten können, während Sie das Blog lesen. In den folgenden Abschnitten werden eine kurze Zusammenfassung der von uns bereitgestellten Dienste, der von uns bereitgestellten Apps, wo der zugehörige Code in diesem Repository und in dem die Änderungen für jeden Blog -Beitrag angeboten werden.
Der Shipfast-API-Code finden Sie im Ordner Server/ShipFast-API. Der Code wird in der Cloud bereitgestellt und unter https://shipfast.demo.approov.io verfügbar gemacht.
Die ShipFast -API ist von v1 nach v4 versioniert, um der Blog -Geschichte zu folgen, und Sie können mit den folgenden URLs auf jede Phase zugreifen:
Die Seite Releases dieses Repositorys enthält eine APK für jede Stufe. Sie sind so eingerichtet, dass Sie sie alle gleichzeitig auf Ihrem Android -Gerät installieren können (sorry iOS im Moment).
Der Code für die Apps befindet sich alle in einem Androidstudio -Projekt: App/Android/Kotlin/ShipFast.
Wir haben in jeder Version der App ein anderes Farbschema verwendet, damit Sie schnell feststellen können, welche ausgeführt werden:
Die Farben haben keine besondere Bedeutung, aber offensichtlich ist Grün die beste.
Der Rogue Web Service, Shipraider, wurde von einem bösen Piraten eingerichtet, um Shipfast -Fahrer zu helfen, die Trinkgelder von Shipfast -Kunden auszunutzen. Der Code finden Sie im Ordner server/shipRiider-ogue-Web.
Jede Version der Website wird aus einer anderen Domain bedient:
Die Shipraider -Website folgt dem gleichen Farbschema wie die mobilen Apps, um zwischen den Versionen zu unterscheiden.
Im Folgenden geben wir einen kurzen Überblick über die in der Blog -Serie verwendeten Techniken, um die API mit Links zu den relevanten Codezeilen und dem zugehörigen Blog -Beitrag zu sperren.
Die häufigste Methode, die von Entwicklern verwendet wird, um zu identifizieren, was eine Anforderung an den API-Server stellt, besteht darin, eine lange Zeichenfolge im Anforderungsheader zu verwenden, die am häufigsten als Api-Key bezeichnet wird. Siehe den ersten Blog-Beitrag.
API -Schlüssel sind sowohl im Server als auch im Client sehr einfach zu implementieren. Dieser App -Code fügt den Schlüssel zu jeder Anforderung hinzu, und der Server validiert die Anforderung mit einer einfachen Header -Prüfung, wie in diesem Code gezeigt.
Leider ist es auch einfach, den Schlüsselschutz des API zu umgehen, da es sich um ein Geheimnis handelt, das auf jeder Anfrage kommuniziert wird. Der zweite Blog in der Serie beginnt damit, wie man den API -Schlüssel mit einem MITM -Angriff (Mann in der Mitte) extrahiert. Der Schlüssel wird dann zur Shipraider -Website hinzugefügt, die in den Anfragen an der Shipfast -API verwendet wird.
Um den Schutz zu verbessern, führt der zweite Blog -Beitrag eine HMAC ein, um API -Anfragen digital zu unterzeichnen und daher zu verhindern, dass sie entführt oder manipuliert werden. Es ist besser als ein API -Schlüssel, da der geheime Teil niemals explizit vom Client an den Server gesendet wird und in dieser Version statisch in den Code eingebettet ist.
Die HMAC -Implementierung ist etwas ausführlicher als die Implementierung der API -Schlüssel, aber sie ist immer noch einfach. Sie können diesen Code für die API -Server -Implementierung und diesen Code für die mobile App -Implementierung überprüfen.
Wenn das HMAC-Geheimnis jedoch hart codiert ist, ist es für einen Angreifer immer noch einfach zu extrahieren. Der dritte Blog -Beitrag zeigt dies durch die Verwendung von Open -Source -Binäranalyse -Tools, um das HMAC -Geheimnis und den zugehörigen Algorithmus anzuzeigen, der zur Unterzeichnung der Anforderungen verwendet wird. Sobald diese in den Shipraider -Code kopiert werden, kann die Rogue -Website wieder einrichten.
Das zweite Angriffsszenario ergab, dass die Verwendung eines statischen Geheimnisses für den HMAC -Algorithmus eine Schwachstelle ist. Die nächste Verteidigung besteht darin, ein dynamisches Geheimnis zu verwenden. eine, die zur Laufzeit berechnet wird. Der dritte Blog -Beitrag erklärt, wie ein statisches Geheimnis mit dynamischen Daten kombiniert werden kann, um ein dynamisches Geheimnis zu ergeben, mit dem der HMAC -Algorithmus initialisiert werden kann.
Die Implementierung für die mobile App ist in diesen Codezeilen zu sehen, während das API -Serveräquivalent hier zu sehen ist.
Das Berechnen des HMAC -Geheimnisses zur Laufzeit macht es schwieriger, zu umgehen, aber nicht unmöglich. Der Angreifer muss nun einen größeren Codeabschnitt verstehen, um das Verhalten auf der Shipraider -Website zu reproduzieren. Der vierte Blog -Beitrag listet dafür mehrere Ansätze auf, wobei ein detaillierteres Beispiel mit App -Repackaging und dem Android Studio -Debugger enthält. Auch hier kann der Angreifer gleichwertiger Code in Shipraider schreiben, um die Shipfast -API weiter zu verwenden.
Der vierte Blog -Beitrag führt die endgültige Sicherheitsmaßnahme in der Serie vor. Die Bescheinigung von Mobile App ist das im Nahe implementierte API -Sicherheitskonzept. Kurz gesagt, negativ überprüft die gesamte App und die Umgebung, in der sie vor dem Aktivieren des Zugriffs auf die API ausgeführt wird. Die App ist der Schlüssel . Es gibt Ihnen ein hohes Maß an Vertrauen, dass Ihre API zu legitimen Fällen Ihrer App gesperrt ist. Dieser Ansatz wird auf unserer Produktübersichtsseite und im zugehörigen Weißbuch ausführlicher beschrieben.
Die negative Integration ist so einfach wie bei Entwicklern für mobile Apps. Fügen Sie Ihren Build den Neuerungs-SDK hinzu und hoffentlich eines der Beispiele für [QuickStart-Integration]] (https://approov.io/docs/latest/approov-integration- examples/mobile-app/), um den Prozess zu beschleunigen, und dann den SDK anrufen, um einen näher Token-Token-Token zu erhalten. Sie können dies in der ShipFast -App in ShipFastApp.KT sehen, um nach den Zeilen zu suchen, denen // *** UNCOMMENT THE CODE BELOW FOR APPROOV *** vorangestellt werden.
Die API -Server -Integration ist ebenfalls einfach: Verwenden Sie eine der vielen JWT -Bibliotheken, um das Anlagen -Token zu überprüfen, bevor Sie auf API -Anforderungen antworten. Die ShipFast-API verwendet das Express-JWT-Knotenpaket, um das Anlagen-Token mit dem checkApproovToken -Rückruf zu überprüfen.
Das erweiterte Verwendungsdokument beschreibt die Build- und Bereitstellungsschritte für jede der Komponenten, aus denen die Schiffsfast- und Shipraider -Dienste ausmachen. Um der Blog -Serie zu folgen, reicht es normalerweise aus, die vom Neigungsteam bereitgestellten und verwalteten Apps und Apps zu nutzen. In diesem Fall müssen Sie diesem Dokument nicht folgen. Sie benötigen es jedoch, wenn Sie die optionale Pentest -Herausforderung versuchen, die am Ende des letzten Blog -Beitrags beschrieben wird.
Die Blogserie als Ganzes zeigt eine allmähliche Verbesserung der API -Sicherheit, indem sichergestellt wird, dass die Anfragen nur aus legitimen Quellen stammen. Die Blogs und der Code in diesem Repository werden verwendet, um zu zeigen, wie einige Schutzmechanismen, die häufig in der API -Entwicklung verwendet werden, leicht umgehen können. Es gipfelt in einer negativen Integration, die das höchste Vertrauen in die überprüften Anfragen von der Shipfast -API verleiht. Wenn Sie die negative Lösung genauer untersuchen möchten, versuchen Sie es nicht mit einer der folgenden Links als Ausgangspunkt:
