Récemment, j'ai écrit sur la protection d'une idée d'application et sur les raisons pour lesquelles il ne vaut pas la peine de breveter son application avant son lancement effectif. En termes de concept de design, d'éléments d'interface utilisateur et de principes UX, il existe une partie ingénierie qui est aussi enchevêtrée qu'importante pour la viabilité du projet.
Si vous pouvez protéger par copyright le design et l'identité, que se passe-t-il derrière les lignes de code ? Sont-elles protégées du plagiat ? Comment se fait-il qu'il y ait autant d'aaps identiques ? Est-ce simplement parce que "les grands esprits se rencontrent" ? Ou bien y a-t-il un déchaînement en cours ? Je vais tenter de répondre à ces questions avec l'aide de mes collègues développeurs mobiles.
Ce qui peut arriver avec des applications non protégées
Le code source des applications est l'essence même de toute application. Des centaines d'heures de travail, toutes les connaissances, les découvertes, les solutions en ruban adhésif et chaque parcelle d'espoir de réussir sont dissimulées dans le code source de l'application. Comme le ventre d'une bête, il est vulnérable et les conséquences de son endommagement sont terribles.
Alors, si quelqu'un soit vole ou décompile un morceau du code source de votre application, soit le code entier, en gros détourne votre application iOS ou Android, que pouvez-vous faire ? Les pires scénarios incluent les résultats suivants:
- Votre application est craquée. Si votre application est payante, le méchant peut en faire une version gratuite et tout simplement tuer votre modèle économique. Cela nécessitera très probablement que vous abandonniez votre projet et en proposiez un autre. Une décision difficile à prendre.
- Votre application est infectée. Ils gardent l'app payante et normale, mais l'infectent avec un virusware ou un malware pour créer des schémas d'escroquerie sur les builds ultérieures. Dans ce cas, vos utilisateurs fidèles reçoivent un coup de pied dans les dents qui ruine tout ce que vous avez construit. C'est un mauvais coup qui vous obligera très probablement à vous retirer du marché, sans parler des problèmes juridiques.
- Votre application devient un cobaye. Si l'application que vous avez créée a un quelconque succès, elle a une cible sur le dos. Si vos concurrents mettent la main sur le code source de votre application, ils la mettront en pièces et obtiendront des morceaux de votre ancien avantage concurrentiel. Cela mettra très probablement fin à la vie de votre application.
Maintenant, détendons-nous un peu et regardons comment et pourquoi le code source de votre application peut être volé. Une fois que l'application est sortie, vous pouvez vous attendre à ce que les gens commencent à s'en amuser.
Est-ce que l'ingénierie inverse de l'application en vaut la peine ?
Alors, en dehors de tout le drame, avoir votre code volé est une déception qui, si elle ne ruine pas votre marque, pourrait être une énorme distraction faisant glisser le temps de ce qui compte vraiment - vos objectifs commerciaux. Chez Shakuro, nous considérons que le code source d'une application est notre responsabilité à 100 %. Sa sécurité, sa sûreté et sa résistance aux balles doivent être constamment testées au fur et à mesure que les fonctionnalités sont mises en œuvre.
Sécurité du code iOS
Nos applications iOS ont un code écrit en Objective-C et Swift qui se compile en un code binaire. Le code source est stocké sur notre dépôt GitHub privé, ou sur des dépôts côté client. L'interaction entre les données utilisateur de l'app-serveur passe par des fonctions natives d'iOS ou un certificat OpenSSL pour crypter le trafic pour une protection supplémentaire.
Ceci transforme essentiellement nos apps iOS en boîtes noires dans lesquelles vous ne pouvez pas vraiment voir. Mais avec une certaine quantité de persistance, ils peuvent y jeter un coup d'œil sous différents angles et pêcher quelque chose. Les apps sont constituées de différentes parties comme :
- L'exécutable crypté - le code compilé, le noyau.
- Les métadonnées - les variables.
- Les frameworks cryptés - les modules.
- Les actifs - les images, les chaînes de caractères, etc.
La partie exécutable est ce qui est généralement blindé pour protéger l'app des intrusions. Les frameworks peuvent également être exploités. Un ingénieur inverse peut travailler avec deux états d'une application - actif et inactif. Il peut étudier le trafic et injecter du code lorsque l'application est en cours d'exécution, et étudier les binaires lorsque l'application n'est pas en cours d'exécution. Le décryptage du code binaire nécessite un ensemble étendu de compétences dignes d'un développeur d'app très compétent.
En dehors de cela, Swift étant une technologie assez récente est sécurisé par nature car l'outillage pour décomposer son code n'existe pas encore. Quant à l'Objective-C, il existe de multiples outils compliqués qui doivent être utilisés spécifiquement pour certaines parties du processus de rétro-ingénierie et qui demandent tellement d'efforts que cela annule presque l'effet, sans parler du fait que c'est contraire à l'éthique et illégal.
Obfuscation du code de l'OS
Si quelqu'un essaie réellement de décompiler le code Swift, il est nativement obfusqué. En citant hotpaw2 de stack overflow : "Xcode convertit également le code Swift en une sorte de bytecode de représentation intermédiaire, appelé bitcode par Apple. Mais, IIRC, le bitcode est dépouillé par Apple avant d'envoyer une app aux clients, et le code compilé de l'app est également crypté par Apple."
Au lieu de mettre du temps à complexifier le code de l'app qui n'est pas visible dans le build, ce que nous nous efforçons vraiment de protéger, ce sont les bibliothèques du SDK qui contiennent des modules personnalisés.
En plus des fonctionnalités natives, nous pouvons utiliser Obfuscator qui est un outil d'obfuscation des chaînes sensibles à la sécurité codées en dur. Obfuscator transforme les chaînes en tableaux d'octets et, au lieu de les faire passer dans l'app, décode les tableaux d'octets pour révéler les chaînes. Il n'exige pas que tout le code de l'app soit obfusqué mais vous donne le choix de n'affecter que les chaînes les plus cruciales.
Sécurité du code Android
Il n'y a aucun moyen d'assurer une sécurité à 100% d'une application Android. Si quelqu'un s'engage à pénétrer dans le code de votre application, il le fera. La seule façon de le combattre est de le rendre insensé.
Dans le cas d'une application iOS écrite en Swift, c'est un processus difficile et laborieux, en raison de sa relative nouveauté, mais qu'en est-il de Java ? Il existe depuis des décennies et il y a des millions de développeurs. Compte tenu des particularités du système d'exploitation Android, voici comment vous pouvez protéger une application. Le code source des applications Android est généralement écrit en Java, mais il n'est pas distribué dans les builds sous forme de bytecode Java, il est plutôt téléchargé dans des fichiers .dex, qui peuvent être décompilés en code source Java. La seule contre-mesure sur laquelle la communauté semble s'accorder est l'obfuscation.
Android Code Obfuscation
L'une des façons les plus puissantes de sécuriser un APK Android est d'utiliser l'obfuscation du code. Cette pratique change régulièrement les noms de variables et les classes de l'app pour rendre les chaînes de code confuses et briser les dépendances. Mais c'est plus que cela. L'obfuscation du code permet également de réduire le code, de cacher certains extraits et de le réduire de manière significative. Certains des outils d'obfuscation les plus populaires sont :
- Proguard
- DexProtector
Ce sont des outils solides qui empêchent les intrusions grâce à certains algorithmes cryptographiques forts tout en injectant des contrôles de sécurité dans les APK Android. L'application peut être bloquée une fois que l'outil se rend compte que le code de l'application est exploité.
La licence d'application Android est une fonctionnalité intégrée qui tente d'appliquer une politique de licence flexible sur une base application par application - chaque application peut appliquer la licence de la manière la plus appropriée pour elle. Elle accorde une sorte de contrôle d'accès à votre application.
"Lorsqu'une application vérifie le statut de la licence, le serveur Google Play signe la réponse au statut de la licence à l'aide d'une paire de clés associée de manière unique à l'application. Votre application stocke la clé publique dans son fichier .apk compilé et l'utilise pour vérifier la réponse sur le statut de la licence."
"Par exemple, une application peut vérifier le statut de la licence, puis appliquer des contraintes personnalisées qui permettent à l'utilisateur de l'exécuter sans licence pendant une période de validité spécifique. Une application peut également restreindre l'utilisation de l'application à un appareil spécifique, en plus de toute autre contrainte." Cette fonctionnalité est déjà utilisée pour intégrer la sécurité et la transparence à l'utilisation du code de l'application côté client.
Lignes directrices générales en matière de sécurité des applications chez Shakuro
Comme il pourrait sembler, le code n'est pas la partie la plus précieuse de votre application, il est certainement le cœur d'une application, mais il est presque contre-intuitif combien il faut pour décompiler le code et construire un clone de celui-ci. Au lieu de cela, il existe des problèmes spécifiques aux mobiles qui affectent l'actif le plus précieux que vous possédez - l'information. C'est l'objectif principal du développeur de garder les informations sécurisées et privées.
Stockage de données
Si une app stocke des données utilisateur, en particulier des informations d'identification, des jetons et des clés d'accès, ces choses doivent être mieux protégées que par un simple fichier Info.plist. Utilisez plutôt les services de trousseau du système natif ou des bibliothèques tierces pour un stockage sécurisé. Utiliser également le cache et ne pas sauvegarder toutes les données sur les services cloud peut permettre d'économiser de l'espace et empêcher quelqu'un de les analyser.
Canaux de communication sécurisés
Le protocole HTTP est une méthode de communication non cryptée entre l'application et le serveur. Les spots Wi-Fi publics auxquels beaucoup de téléphones se connectent quotidiennement peuvent être le moyen d'attaques man-in-the-middle. Par conséquent, si des éléments confidentiels ou critiques pour la sécurité sont envoyés dans les deux sens, HTTPS est le canal de communication le plus sûr. Pour les protocoles de réseau personnalisés, utilisez TLS.
Données de l'utilisateur
Alors que de plus en plus d'apps s'intègrent à nos vies grâce à diverses fonctionnalités utiles, les téléphones deviennent les hubs ultimes d'informations personnelles et sensibles qui doivent être stockées de manière responsable. Si un utilisateur accorde à votre app l'accès à ces informations, elles ne doivent pas être dupliquées et stockées séparément quelque part. Nous réfléchissons fortement à l'endroit où nous stockons les informations et n'utilisons que des sources non compromises.
Conseils spécifiques à Android
- Évitez Webview en raison des vulnérabilités de l'interface Javascript.
- Évitez la redélégation de permission en raison de l'accès non autorisé d'apps tierces.
- Éviter les intentions en raison des risques d'être mis sur écoute.
- Éviter les injections SQL en raison de l'introduction involontaire de la vulnérabilité.
Bottomline
L'une des meilleures façons de résister est de faire en sorte que le jus ne vaille pas la peine d'être pressé. Le but du piratage d'app est de voler une app et d'obtenir une sorte de récompense pour cela. Si l'importance de la récompense ne vaut pas le temps et les efforts investis, les pirates et hackers opportunistes abandonneront. En fin de compte, ce sont aussi des hommes d'affaires... non éthiques et illégaux, mais soutenus par une logique tordue.
L'écrasante majorité des développeurs disent que si quelqu'un veut faire de l'ingénierie inverse sur une appli, ils le feront.
Il est juste de dire que le code source n'est pas la raison pour laquelle les clients apprécient les développeurs. Oui, c'est le produit et le résultat de tout le travail acharné, mais ce n'est pas la raison pour laquelle ils nous paient. Lorsque les clients engagent une équipe, ils investissent dans la solution de leur tâche qui va au-delà du simple code. Ils décident d'engager une équipe en fonction de ses capacités techniques, de son expérience, de son modèle économique, etc. Nous gagnons les clients sur la façon dont nous communiquons et faisons un effort pour comprendre sincèrement leurs projets, et montrons notre engagement à son égard une fois que nous avons commencé.