shipfast api protection
vor, improvments, fixes and security updates
Accueillir! Ce référentiel fait partie de cette série d'articles de blog sur les techniques pratiques de sécurité des API. La série vous guide tout au long du processus de défense d'un backend API mobile contre divers exploits qu'un attaquant peut utiliser pour accéder aux données qu'il contient. Dans ce scénario de démonstration, l'attaque permet aux utilisateurs réels du système d'obtenir un avantage commercial injuste aux dépens de l'entreprise.
Ce référentiel contient les trois composants utilisés pour décrire l'histoire de Shipfast:
Nous avons conservé les 3 projets dans le même référentiel et structuré le code pour inclure toutes les étapes de la progression de la série de blogs. Nous espérons que cela facilite la compréhension dans son ensemble.
Après avoir établi la scène dans le premier article de blog, les entrées successives montrent comment les mesures de sécurité peuvent être renforcées (ou contournées) en utilisant des liens vers le code dans ce référentiel GitHub, le cas échéant. La série de blogs peut être résumé en faisant référence à la principale méthode de sécurité en discussion dans chacune:
Nous fournissons des déploiements disponibles gratuitement des deux services et des APK pour que vous puissiez télécharger et installer, afin que vous puissiez travailler avec eux pendant que vous lisez le blog. Les sections suivantes donnent un bref résumé des services que nous avons déployés, des applications que nous fournissons, où trouver le code associé dans ce référentiel et où se trouvent les modifications de chaque article de blog.
Le code API ShipFast peut être trouvé dans le dossier Server / ShipFast-API. Le code est déployé dans le cloud et mis à disposition sur https://shipfast.demo.approov.io.
L'API ShipFast est versée de v1 à v4 pour suivre l'histoire du blog et vous pouvez accéder à chaque étape en utilisant les URL suivantes:
La page de versions de ce référentiel contient un APK pour chaque étape. Ils sont configurés afin que vous puissiez les installer tous en même temps sur votre appareil Android (désolé non iOS en ce moment).
Le code pour les applications est tout dans un projet AndroidStudio: app / Android / Kotlin / Shipfast.
Nous avons utilisé un schéma de couleurs différent dans chaque version de l'application afin que vous puissiez identifier rapidement lequel s'exécute:
Les couleurs n'ont pas de signification particulière, mais évidemment, le vert est le meilleur.
Le service Web Rogue, Shiprader, a été mis en place par un pirate maléfique pour aider les conducteurs à Shipfast à profiter des pourboires des clients de Shipfast. Le code se trouve dans le dossier Server / Shipraider-Rogue-Web.
Chaque version du site Web est servie à partir d'un domaine différent:
Le site Web de Shipraider suit le même schéma de couleurs que les applications mobiles pour différencier les versions.
Ci-dessous, nous donnons un bref aperçu des techniques utilisées dans la série de blogs pour verrouiller l'API avec des liens vers les lignes de code pertinentes et le blog associé.
La méthode la plus courante utilisée par les développeurs pour identifier ce qui fait une demande au serveur API est d'utiliser une longue chaîne dans l'en-tête de demande, le plus souvent appelé une Api-Key , voir le premier article de blog.
Les clés API sont très simples à implémenter dans le serveur et le client. Ce code d'application ajoute la clé à chaque demande et le serveur valide la demande avec une vérification simple d'en-tête, comme le montre ce code.
Malheureusement, le contournement de la protection des clés de l'API est également facile, car c'est un secret communiqué à chaque demande. Le deuxième blog de la série commence par montrer comment extraire la clé API avec une attaque MITM (homme au milieu). La clé est ensuite ajoutée au site Web de Shipraider pour être utilisée dans les demandes qu'il fait à l'API ShipFast.
Pour améliorer la protection, le deuxième article de blog introduit un HMAC pour signer numériquement les demandes d'API et donc les empêcher d'être détournés ou falsifiés. Il est mieux qu'une clé API car la partie secrète n'est jamais explicitement envoyée du client au serveur et dans cette version, elle est intégrée statiquement dans le code.
L'implémentation HMAC est un peu plus élaborée que la mise en œuvre des clés de l'API, mais elle est toujours simple. Vous pouvez vérifier ce code pour l'implémentation du serveur API et ce code pour l'implémentation de l'application mobile.
Cependant, si le secret HMAC est codé en dur, il est toujours facile pour un attaquant d'extraire. Le troisième article de blog le démontre en utilisant des outils d'analyse binaire open source pour révéler le secret HMAC et l'algorithme associé utilisé pour signer les demandes. Une fois que ceux-ci sont copiés sur le code Shipraider, le site Web Rogue peut être à nouveau opérationnel.
Le deuxième scénario d'attaque a révélé que l'utilisation d'un secret statique pour l'algorithme HMAC est un point faible. La prochaine défense consiste à utiliser un secret dynamique; celui qui est calculé lors de l'exécution. Le troisième article de blog explique comment combiner un secret statique avec des données dynamiques pour donner un secret dynamique avec lequel initialiser l'algorithme HMAC.
L'implémentation de l'application mobile peut être vue dans ces lignes de code tandis que l'équivalent du serveur API peut être vu ici.
Computer le secret HMAC au moment de l'exécution rend plus difficile le contournement mais pas impossible. L'attaquant doit désormais comprendre une section de code plus importante afin de reproduire le comportement du site Web de Shipraider. Le quatrième article de blog répertorie plusieurs approches pour cela, donnant un exemple plus détaillé en utilisant le reconditionnement des applications et le débogueur Android Studio. Encore une fois, l'attaquant peut écrire du code équivalent dans Shiprader pour continuer à utiliser l'API ShipFast.
Le quatrième article de blog, présente la mesure de sécurité finale de la série. L'attestation des applications mobiles est le concept de sécurité de l'API mis en œuvre dans ApproV. En un mot, ApproV vérifie l'ensemble de l'application et l'environnement dans lequel il s'exécute avant d'activer l'accès à l'API - l'application est la clé . Il vous donne un degré élevé de confiance que vos accès API sont verrouillés aux instances légitimes de votre application. Cette approche est décrite plus en détail dans notre page d'aperçu du produit et dans le livre blanc associé.
L'intégration ApproV est aussi simple que possible pour les développeurs d'applications mobiles. Ajoutez le SDK Approov à votre version, espérons-le en utilisant l'un des [Exemples d'intégration QuickStart]] (https://approov.io/docs/latest/approov-integration-examples/mobile-app/) pour accélérer le processus, puis appeler le SDK pour obtenir un jeton d'approv pour inclure sur les demandes d'API. Vous pouvez le voir dans l'application Shipfast dans ShipfastApp.kt, recherchez les lignes précédées par // *** UNCOMMENT THE CODE BELOW FOR APPROOV *** .
L'intégration du serveur API est également simple: utilisez l'une des nombreuses bibliothèques JWT pour vérifier le jeton ApproV avant de répondre aux demandes d'API. L'API ShipFast utilise le package de nœud Express-JWT pour vérifier le token ApproV avec le rappel checkApproovToken .
Le document d'utilisation avancé décrit les étapes de construction et de déploiement pour chacun des composants qui composent les services Shipfast et Shiprader. Pour suivre la série de blogs, il est normalement suffisant d'utiliser les services et les applications déployés et entretenus par l'équipe ApproV, auquel cas vous n'avez pas besoin de suivre ce document. Cependant, vous en aurez besoin si vous essayez le défi de pentisting facultatif, décrit à la fin du dernier article de blog.
La série de blogs, dans son ensemble, montre une amélioration progressive de la sécurité des API en veillant à ce que les demandes ne proviennent que de sources légitimes. Les blogs et le code de ce référentiel sont utilisés pour montrer comment contourner facilement certains mécanismes de protection qui sont couramment utilisés dans le développement d'API. Il culmine dans une intégration de l'approv qui donne le plus haut degré de confiance dans les demandes vérifiées reçues par l'API Shipfast. Si vous souhaitez explorer la solution ApproV plus en profondeur, pourquoi ne pas essayer l'un des liens suivants comme point de saut:
