Quand on parle de sécuriser une application web ou mobile, on pense généralement qu’il suffit de “crypter” les mots de passe (en réalité on dit “chiffrer”, d’ailleurs). Et surtout, quand on est entrepreneur, on considère qu’il n’est pas nécessaire de s’y intéresser, en tout cas, pas avant d’avoir des millions d’utilisateurs.
Et pourtant… Et si penser sécurité dès la création de son produit était en réalité une bonne chose ?
Chez theTribe, on pense qu’un bon design produit doit vous apporter de la sérénité sur tous les plans ; répondre aux attentes de vos utilisateurs, à leurs besoins de sécurité, et à vous abriter des menaces qui pourraient faire écrouler votre projet.
Encore un doute ? Paul Julienne, développeur chez theTribe, lève le voile sur ce sujet peu accessible, en se penchant sur la question de la sécurité des applications mobiles.
Sommaire :
- Pourquoi sécuriser votre application mobile le plus tôt possible ? 🛡
- Sécuriser une application mobile, ça coûte cher ? 💰
Failles de sécurité dans le mobile : quelle est l’étendue des dégâts ? 💥
Les smartphones ont résolu beaucoup de frustrations de leurs utilisateurs, grâce aux magnifiques applications qui voient le jour quotidiennement. En 2022, on compte 4 830 000 d’applications disponibles au téléchargement et, tenez-vous bien, près de 145 milliards de téléchargements en 2022.
Or, certains acteurs du marché diagnostiquent que seules 5% de ces applications implémentent les bases de la sécurité… soit 4 588 500 applications-gruyère 😱.
Fort heureusement, une grande majorité du Play Store / Apple Store ne dépasse pas les quelques milliers de téléchargements. En tant qu’utilisateur, on a quand même beaucoup de chances d’être épargné… ou pas !
Car tenez-vous bien : actuellement Kaspersky déclare que plus de 3.4 millions de paquets sont malveillants. Sur nos 4.8 millions d’applications mobiles en circulation, finalement, on ne se sent pas tellement en sécurité.
Il va sans dire que votre application mobile n’est pas malveillante.
Mais qu’en est-il des autres applications installées sur le smartphone de vos utilisateurs ? Qui vous dit que certains n’ont pas téléchargé des applications Trojan (quasiment 20% du lot d’après Kaspersky) ?
Une bête petite application de fond d’écran, si elle contient un Trojan, peut accéder aux données de votre app et venir remettre en question la totalité de votre infrastructure.
On peut prendre l’exemple d’une application de banque qui, par chance, contient une authentification à deux facteurs. C’est extra ! 💪🏼
Mais le hic : une fois l’utilisateur connecté, son token réside dans les « sharedPreferences » du téléphone…
Et hop : la super application-espion de fond d’écran vient de récupérer un accès aux comptes de l’utilisateur, en plus de l’adresse de mon API. C’est la catastrophe pour mon utilisateur, et un risque pour mon API si elle aussi est vulnérable.
Vous pensez que j’exagère ?
Pourtant, des catastrophes exposant des données sensibles sont arrivées plusieurs fois ces derniers temps, et pas seulement chez des éditeurs de logiciels douteux.
Voyez par vous-même.
- Slack, 2022 : une faille a été détectée, présente depuis 4 ans, laissant transiter le mot de passe des utilisateurs. On ne sait pas combien de personnes ont été affectées (peut-être 50 000 par an ?) et si cette faille a été exploitée.
- Amazon Ring : 4 000 000 d’utilisateurs ont vu leur position exacte exposée par l’API d’Amazon.
- Faille d’Apple iMessage : les 900 000 000 d’appareils iOS pouvaient, sans défense/précaution possible, devenir de véritables mouchards portables et quasiment indétectables.
« Les smartphones et autres appareils mobiles font partie des vecteurs d’attaque les plus simples pour les hackers. […] Nous devons souligner que ces appareils détiennent la clé de nos vies – à la fois professionnelles et individuelles. Parce qu’ils sont toujours proche de nous, dans nos poches, on a une fausse perception de la sécurité » – Ondrej Krehel, CEO & Fondateur de LIFARS
Pourquoi les hackers s’en prennent-ils aux applications mobiles ? 🥷
Ces trois précédents exemples illustrent parfaitement les principales cibles des hackers, à savoir les identifiants, les vulnérabilités des API et l’intégrité de l’appareil. Mais bien souvent ces cibles ne sont que le début, le point d’entrée pour les hackers.
On s’attaque aux identifiants généralement pour étendre la surface d’attaque :
- Et si « mon@email.fr » et « MonM0t2Passe » étaient également utilisés pour mon compte Google ? Mon compte Paypal ? Impot.gouv ? … Un mot de passe est en moyenne réutilisé 13 fois par personne.
S’attaquer aux API, c’est souvent pour compromettre une infrastructure :
- Et si un hacker arrivait, via une élévation de privilège depuis l’API, à accéder à des fonctions de versement de fichier dans mon serveur, lui permettant d’ajouter une porte dérobée (backdoor) et ainsi espionner toute la baie du datacenter ?
Et de son côté, l’appareil de l’utilisateur peut être très utile pour gagner en « échelle » et/ou « impact »
- Et si, comme l’union fait la force, un hacker créait une flotte d’appareils zombies en injectant un malware dans une mise-à-jour vérolée de l’application ?
Quelles sont les sources des failles de sécurité ? 🔓
On comprend la motivation des hackers, mais il est difficile de comprendre et d’accepter les raisons pour lesquelles ça reste possible. En tant qu’utilisateur de systèmes que l’on paie parfois cher (iOS, Android, Windows, Macintosh…) on s’attendrait à ce que tout cela ne soit pas possible.
Et on en vient aux raisons, les vraies.
Pour en faire une phrase simple à retenir : « Il est plus simple de trouver comment contourner une règle plutôt que de créer des règles qui empêchent tous contournements ».
Parmi les raisons qui expliquent les problèmes de sécurité dont on a parlé, on retrouve, de manière, non exhaustive :
- Un manque de chiffrement des données. Le chiffrement (encryption en anglais) permet de faire en sorte que personne ne puisse comprendre les données en dehors de ses émetteurs et destinataires. Un chiffrement, même faible, c’est toujours mieux que rien. Cela devrait être d’office inclus dans les temps/coûts de développement.
- Des faiblesses liées au système d’exploitation (OS), il y en aura toujours, et certaines existeront à jamais. Par exemple : avant le démarrage de l’OS et des sécurités qu’il impose, la mémoire est libre de tout contrôle. C’est comme si à chaque ouverture d’une banque, il y avait un moment où tous les verrous, alarmes et personnels n’étaient pas encore là… pratique !
- La rétro-ingénierie permet aux hackers de faire le chemin inverse de la conception, pour tout connaître du système puis de comprendre comment l’exploiter. Dans le développement, cela porte un nom compliqué, mais on en fait tous dans la vie de tous les jours. On démonte un jeu/matériel cassé pour le réparer : c’est de la rétro-ingénierie, et c’est pour cette raison que les garanties sont caduques quand on le fait nous-même – et ce n’est pas forcément un mal. Certaines entreprises qui fabriquent du hardware rendent cette étape plus fastidieuse (ex : modifier des composants d’un MacBook par rapport un Windows/Linux standard). Dans le logiciel, c’est possible aussi, mais on ne peut jamais complètement l’empêcher.
- L’élévation de droit est un très bon moyen de faire des choses qui ne nous sont pas autorisées normalement. Côté mobile et console de jeux, c’est une pratique très courante (jailbreak, root) pour éviter de payer certains services (applications, abonnements…). Cependant, cela revient à mettre tous ses biens personnels (données du téléphone) dans un carton au bord de la route : tout le monde peut voir ce qu’il y a dedans et s’il en a le courage, il peut s’en servir. Dans certains cas, il vaut mieux empêcher votre application d’être installée sur un terminal « jailbreaké »; vous ne pouvez pas espérer de vos utilisateurs qu’ils protègent les données de votre application par eux-mêmes !
- L’écoute des communications (sniffing, man in the middle), l’exposition des « debuggers », les attaques à l’émulateur…
Bref : il y a plein de moyens d’expliquer pourquoi il y aura toujours des attaques.
Heureusement il existe des solutions pour les limiter. Même si quel que soit l’effort fourni, aucun système n’est fiable à 100%.
Prenons le chiffrement des données comme exemple. Si un hacker cherche à « lire » une donnée qui a été encryptée par la Rolls-Royce des algorithmes actuels, cela lui prendrait bien plus qu’une vie avec les outils qu’il a à sa disposition… Mais si demain il avait un ordinateur quantique sous la main, il ne lui faudrait que quelques instants !
En conclusion : en matière de sécurité, il ne faut surtout pas ne rien faire ; mais même en donnant le maximum, on n’est jamais infaillible. Entourez-vous d’experts comme theTribe pour mettre la barre au bon niveau 😉
Pourquoi sécuriser votre application mobile le plus tôt possible ? 🛡
Vous vous dites peut-être en lisant ces mots : “Sécuriser c’est bien, mais si ça coûte de l’argent, du temps et qu’en plus c’est jamais suffisant… Je laisse tomber !”
Je vais vous donner quelques raisons de rejoindre le bon côté de la force.
👉 Éviter les sanctions et les retombées économiques d’une faille
La toute première, c’est déjà de se dire que 60% des petites entreprises ferment 6 mois après avoir été hackées…
Aujourd’hui, sécuriser c’est garantir à vos utilisateurs que les données qu’ils vous confient sont maîtrisées et au passage, éviter des sanctions financières trop lourdes en cas de problème.
D’un point de vue légal, il est détaillé dans le RGPD (paragraphe 39) que « Les données à caractère personnel devraient être traitées de manière à garantir une sécurité et une confidentialité appropriées, y compris pour prévenir l’accès non autorisé à ces données […]».
Alors effectivement,”approprié”, c’est vague, et chacun peut l’interpréter comme il le souhaite.
Le plus simple, c’est encore de se faire accompagner par des experts (🫡) et s’il faut aller plus loin, de passer par une certification (cf article 25 du RGPD) ; cela limite le risque et l’impact financier qu’une potentielle faille pourrait engendrer.
👉 Conserver la confiance de vos utilisateurs
Sécuriser ses données c’est aussi s’assurer de conserver une confiance auprès de vos utilisateurs, et l’utilisateur c’est le nerf de la guerre dans le monde de la tech.
On a trop tendance à penser que le produit suffit à les fidéliser, à les conserver, mais il ne faut pas oublier que l’utilisateur est opportuniste ! D’autant plus quand l’outil est gratuit. D’ailleurs, les experts le disent : 70% des utilisateurs évitent les entreprises qui ont eu des failles de sécurité.
Un bon exemple serait celui du rachat de Whatsapp par Facebook (alias Meta). La simple annonce de ce rachat a fait envisager une bonne partie des utilisateurs de migrer vers Telegram, pour des raisons de confidentialité.
👉 Maintenir votre image de marque
Maintenant imaginez-vous qu’en plus de ces deux points qui peuvent à eux seuls plomber votre business, s’ajoute l’impact sur l’image de marque que vous avez construite avec tant d’effort. Il vous faudrait, en plus de dépenser de bonnes sommes pour consolider vos failles, dépenser encore de l’énergie et de l’argent dans du marketing…
👉 Garder votre propriété intellectuelle
En bonus, notamment lorsqu’on construit des solutions particulièrement novatrices, on peut penser à la propriété intellectuelle, qu’on ne valorise pas si souvent.
Imaginez qu’une personne utilise le code de votre application compilée (rétro-ingénierie), les données de votre base de données usurpées, et des attaques DDOS sur votre infrastructure, pour lancer en 2 semaines une application clone qui aspirerait tout votre business… Bon : c’est un scénario peu probable, j’en conviens, mais l’idée a de quoi révolter 😡 et ça n’est pas hors de portée de certains hackers.
Sécuriser une application mobile, ça coûte cher ? 💰
Mais combien ça coûte, la sécurité ? Faut-il encore dépenser plus pour avoir une appli mobile digne de confiance ? Pas tout à fait. Notre credo chez theTribe, ce serait, pour faire court : “Dépenser mieux pour dépenser moins”.
Combien ça coûte, une faille de sécurité ? 🤔
“Dépenser moins ? Aucun problème, je ne dépense rien, je fais profil bas et ça passera !”
Mauvais idée ! Avant de penser “coûts” de la sécurité, il faudrait déjà connaître le coût de l’absence de sécurité.
Alors intéressons-nous aux finances 🤑
Une violation de données, en 2022, ça coûte cher… En France c’est en moyenne 4,35 millions d’USD d’après IBM. Et encore, c’est une moyenne : sur des fuites de plus de 50 millions de données, c’est plutôt de l’ordre de 387 millions. Mais intéressons-nous au détail de ces coûts.
La détection et l’escalade (détecter la violation et son origine) ainsi que la riposte post-violation (appliquer des correctifs et rétablir le service entre autres) représentent 60% de la répartition des coûts d’une violation.
Et ça tombe bien, dès la conception on peut adresser ces questions !
Comment éviter ces coûts ? 🔎
On ne pourra pas éliminer le risque, mais on peut diminuer sa fréquence et son impact en pensant dès le début à l’hypothèse d’une attaque. On ne s’attardera pas dans cet article sur les moyens concrets (contactez-nous si le sujet vous intéresse), mais l’idée, c’est de réduire au maximum les moyens (vecteurs), la latence dans l’identification, et l’action pour enfin diminuer l’ampleur et l’impact financier.
Toujours pas convaincu ? Sachez que dans cette même étude d’IBM, on apprend qu’on fait en moyenne 3 millions d’économies en déployant des solutions de protection !
Ces chiffres vous semblent sans doute délirants, surtout si votre application n’en est qu’à ses débuts. Bien sûr, on ne va pas vous demander de lever 1 million d’euros uniquement pour sécuriser votre application mobile 😉
Ce que l’on vous propose, c’est de faire selon vos besoins, de prioriser les points cruciaux, et de prévoir les lots futurs, pour éviter qu’un jour, vous ne soyez face à ce surcoût de 3 millions.
Impact de la sécurisation sur le coût d’une application mobile : exemple concret 📝
Admettons que vous développiez une application d’une valeur de 80 000 € pour un lot de 10 fonctionnalités très intéressantes.
Vous la mettez sur le marché et, ensuite, vous souhaitez la faire évoluer afin de la sécuriser. Vous vous retrouvez à devoir re-factoriser votre code, faire face à des problèmes que vous n’aviez pas anticipés et il vous en coûtera finalement 40 000€ de plus. Vous avez donc une application de 120 000 € pour 10 fonctionnalités.
Maintenant, après avoir lu cet article, vous vous dites que vous voulez développer la même application mais en anticipant la partie sécurité.
Vous développez donc un premier lot d’une même valeur de 80 000 € mais contenant seulement 7 des superbes fonctionnalités prévues, puisqu’on a passé du budget et du temps à sécuriser et anticiper la suite.
Vous la mettez sur le marché et vous entamez les évolutions des 3 fonctionnalités manquantes. Vous avez anticipé la sécurisation, et ne faites face à aucun frais de re-factorisation. Vous vous retrouvez avec un second lot qui vous aura coûté seulement 20 000 €. Votre application vous a finalement coûté 100 000 € pour 10 fonctionnalités (soit 20 000 € d’économies par rapport au premier scénario).
Ajoutons qu’en cas de fuite, dans le premier cas, vous n’aurez pas limité les dégâts et vous payez le prix fort. Tandis que dans le second cas, vous aurez certainement eu des moyens de réagir plus rapidement, de corriger efficacement et peut-être même de réduire les sanctions, en prouvant vos efforts quant à la sécurité de vos utilisateurs.
Si vous m’avez lu jusqu’ici, merci, j’espère que vous avez appris quelque chose et surtout, j’espère vous avoir convaincu de l’enjeu de la sécurité pour votre application mobile – et c’est également valable pour votre application web.
Si vous vous demandez quelles sont les bonnes pratiques pour sécuriser votre application, contactez-nous !
