Meilleures pratiques en matière d'applications sécurisées pour une meilleure cybersécurité
À l'ère des vecteurs élevés et très variés de menaces de cybersécurité, le maintien d'une bonne hygiène pour protéger les utilisateurs de vos applications est essentiel pour le développeur d'applications, le consommateur et la sécurité de l'utilisateur de l'application.
La stratégie et les techniques choisies pour protéger la sécurité des utilisateurs d'applications dépendent des fonctionnalités que l'application offre aux utilisateurs, mais les pratiques suivantes devraient être au premier plan des préoccupations des développeurs :
Authentification
Autorisation
Stockage des données
Anti-fraude et anti-retournement
Examinons chacun de ces quatre domaines.
Authentification
Valider l'identité de l'utilisateur et garantir un accès légitime. Les exemples incluent la biométrie, les numéros d'identification personnels ou les générateurs de codes d'authentification multifactorielle.
Mettre en œuvre l'authentification "quelque chose que vous connaissez" comme l'un des facteurs de l'AMF.
L'expression "quelque chose que vous connaissez" représente une couche fondamentale de vérification de l'identité impliquant des informations connues uniquement de l'utilisateur, telles qu'un code PIN (numéro d'identification personnel), un mot de passe, un motif, etc.
La mise en œuvre de l'option "quelque chose que vous connaissez" comme l'un des facteurs de l'AMF garantit un niveau de base de vérification de l'identité en demandant aux utilisateurs de fournir des informations uniques associées à leurs comptes.
Mettre en œuvre l'authentification "quelque chose que vous avez" comme l'un des facteurs de l'AMF.
Les utilisateurs doivent s'authentifier à l'aide d'un dispositif physique, d'une application ou d'un jeton qui génère des informations d'authentification, qui peuvent inclure des mots de passe à usage unique (OTP) basés sur le temps. Parmi les exemples de jetons, on peut citer les jetons logiciels, les jetons matériels et les OTP par SMS.
La mise en œuvre d'un élément que vous possédez comme l'un des facteurs de l'AMF ajoute de la complexité au processus d'authentification en exigeant la possession d'un élément tangible, ce qui réduit considérablement la probabilité d'un accès non autorisé.
Les développeurs doivent utiliser un OTP basé sur le temps pour les jetons logiciels, les jetons matériels et l'OTP par SMS. Les lignes directrices suivantes doivent être suivies :
La durée de validité d'un OTP ne doit pas dépasser 30 secondes.
Un OTP incorrect après trois tentatives doit être invalidé et la session de l'utilisateur doit être révoquée ou rejetée.
Mettre en œuvre l'authentification "quelque chose que vous êtes" comme l'un des facteurs de l'AMF.
Something-You-Are demande aux utilisateurs de s'authentifier à l'aide d'identifiants biométriques tels que les empreintes digitales, les scans de la rétine ou la reconnaissance faciale.
La mise en œuvre du facteur "quelque chose que vous êtes" comme l'un des facteurs d'AMF ajoute un facteur d'authentification hautement personnalisé et difficile à reproduire. Il constitue un moyen plus solide de vérifier l'identité de l'utilisateur que les facteurs Something-You-Know et Something-You-Have, réduisant ainsi le risque d'accès non autorisé.
Les développeurs doivent limiter les fonctionnalités des applications sur les appareils dépourvus d'environnement matériel exécuté de confiance (TEE) ou de biométrie (par exemple, les appareils Android dépourvus de TEE peuvent être détectés à l'aide de l'API Android "isInsideSecureHardware") et doivent invalider l'authentification biométrique si des changements interviennent dans le mécanisme biométrique, comme l'enregistrement d'une nouvelle empreinte digitale sur l'appareil. Les plateformes IOS et Android prennent en charge le paramétrage d'une clé cryptographique d'application pour qu'elle expire en réponse à de tels changements.
Utiliser des facteurs contextuels pour l'authentification.
Les facteurs contextuels introduisent des éléments dynamiques tels que la localisation de l'utilisateur et les attributs de l'appareil. Alors que l'AMF fournit une couche de sécurité solide en exigeant plusieurs facteurs d'authentification, l'intégration de facteurs contextuels crée un processus d'authentification plus complet et adaptatif qui peut offrir des avantages supplémentaires pour faire face à l'évolution des risques d'accès non autorisé.
La mise en œuvre de facteurs contextuels minimise la dépendance à l'égard des informations d'identification statiques, ce qui complique la tâche des acteurs malveillants qui tentent d'obtenir un accès non autorisé. Les développeurs doivent prendre en compte les facteurs contextuels suivants pour vérifier l'identité d'un utilisateur :
Géolocalisation: Autoriser l'accès en fonction de l'emplacement réel d'un appareil à l'aide de la géolocalisation par GPS, Wi-Fi ou adresse IP.
Type d'appareil: Autoriser l'accès en fonction des caractéristiques de l'appareil. Par exemple, la taille de l'écran peut déterminer s'il s'agit d'un smartphone ou d'une tablette.
Mettre en œuvre une authentification de session sécurisée.
L'authentification de session sécurisée garantit une gestion solide des sessions pour l'authentification avec ou sans état. Une mauvaise gestion des sessions, que l'application utilise des méthodes d'authentification avec ou sans état, peut entraîner des menaces pour la sécurité, telles qu'un accès non autorisé, un détournement de session ou une atteinte à la protection des données.
La mise en œuvre d'une authentification de session sécurisée pour les sessions avec état utilise des identifiants de session sécurisés, une communication cryptée et des délais d'attente appropriés pour empêcher tout accès non autorisé. Pour l'authentification sans état, elle garantit que les jetons sont inviolables et maintiennent l'intégrité de l'authentification sans s'appuyer sur un stockage côté serveur.
Mettre en œuvre l'authentification sécurisée avec état.
L'authentification sécurisée avec état implique la protection et le maintien de sessions persistantes. Bien que l'authentification par état offre une expérience utilisateur transparente grâce à des sessions persistantes, elle peut être vulnérable à diverses menaces de sécurité, telles que des acteurs malveillants qui tentent de voler les identifiants de session.
L'authentification sécurisée avec état protège les comptes d'utilisateurs contre les accès non autorisés et les vulnérabilités potentielles associées à la gestion des sessions, sans compromettre l'équilibre entre la convivialité et la sécurité.
Les développeurs doivent identifier les points de terminaison côté serveur qui exposent des informations sensibles ou des fonctionnalités critiques et adopter les meilleures pratiques suivantes en matière d'authentification de session avec état :
Rejeter les demandes dont les identifiants de session ou les jetons sont manquants ou invalides.
Générer des identifiants de session de manière aléatoire du côté du serveur sans les ajouter aux URL.
Renforcez la sécurité de l'identifiant de session en lui conférant une longueur et une entropie adéquates, de sorte qu'il soit difficile de le deviner.
L'échange d'identifiants de session se fait uniquement par le biais de connexions HTTPS sécurisées.
Évitez de stocker les identifiants de session dans un espace de stockage permanent.
Vérifier les identifiants de session pour l'accès des utilisateurs aux éléments privilégiés de l'application.
Terminer les sessions du côté du serveur, en supprimant les informations de session en cas de dépassement de délai ou de déconnexion.
Mettre en œuvre l'authentification sécurisée sans état.
L'authentification sécurisée sans état implique des pratiques de jetons sécurisés pour une authentification efficace et évolutive.
l'authentification sans état. Si l'authentification sans état présente des avantages, elle peut être plus vulnérable aux menaces de sécurité telles que l'usurpation d'identité si les jetons ne sont pas générés, transmis et stockés de manière sécurisée.
L'authentification sans état garantit que chaque jeton est traité en toute sécurité, tout en bénéficiant d'avantages en termes d'efficacité et d'évolutivité, et en réduisant le risque d'accès non autorisé. Les développeurs devraient adopter les meilleures pratiques suivantes en matière d'authentification de session sans état :
Générer des jetons côté serveur sans les ajouter aux URL.
Renforcez la sécurité du jeton en lui conférant une longueur et une entropie adéquates, ce qui rend les devinettes difficiles.
L'échange de jetons se fait uniquement par le biais de connexions HTTPS sécurisées.
Vérifier qu'aucune donnée sensible, telle que des informations confidentielles, n'est incorporée dans les jetons.
Évitez de stocker les jetons dans un espace de stockage persistant.
Vérifier les jetons d'accès des utilisateurs aux éléments privilégiés de l'application.
Terminer les jetons du côté du serveur, en supprimant les informations relatives aux jetons en cas de dépassement de délai ou de déconnexion.
Sur le plan cryptographique, signer les jetons à l'aide d'un algorithme sûr, en évitant d'utiliser des algorithmes nuls.
Mettre en place une clôture de session sécurisée en cas de déconnexion, d'inactivité ou de fermeture de l'application.
La clôture de session sécurisée permet de fermer efficacement les sessions des utilisateurs. Des acteurs malveillants peuvent exploiter des points d'accès persistants si les sessions ne sont pas gérées de manière appropriée dans des scénarios tels que la déconnexion, l'inactivité ou la fermeture d'une application.
La mise en œuvre d'une terminaison de session sécurisée en cas de déconnexion, d'inactivité ou de fermeture de l'application peut réduire considérablement le risque d'accès non autorisé en mettant automatiquement fin aux sessions des utilisateurs et en protégeant les informations des utilisateurs contre l'accès par des parties non autorisées. Les développeurs devraient :
Réauthentifier les utilisateurs après une déconnexion, l'inactivité de l'application, l'oisiveté, la mise en arrière-plan, les délais de session absolus ou la fermeture abrupte/forcée.
Le serveur génère de nouveaux identifiants de session afin d'empêcher la fixation de la session lorsque les utilisateurs atteignent un nouveau niveau d'authentification.
S'assurer que la fin de la session comprend l'effacement ou la suppression de l'autorisation de tous les jetons ou identifiants de session stockés localement.
Déterminer la valeur du délai d'inactivité en fonction du risque et de la nature de la fonctionnalité.
Mettre en place une protection contre la force brute pour l'authentification.
Les attaques par force brute impliquent des tentatives automatisées et systématiques de deviner les informations d'identification de l'utilisateur, par exemple en essayant diverses combinaisons de noms d'utilisateur et de mots de passe pour obtenir un accès non autorisé.
La protection contre la force brute limite le nombre de tentatives de connexion au cours d'une période donnée. La mise en œuvre d'une protection contre la force brute pour l'authentification peut réduire considérablement le risque d'accès non autorisé, protéger les comptes d'utilisateurs et maintenir l'intégrité du processus d'authentification. Les développeurs doivent mettre en œuvre des mécanismes de force brute en suivant les meilleures pratiques suivantes :
Mettre en œuvre des contrôles anti-automatisation.
Appliquer une limitation de taux pour les tentatives de connexion.
Incorporer des délais progressifs (par exemple, 30 secondes, 1 minute, 2 minutes, 5 minutes) pour les tentatives de connexion.
N'oubliez pas que tous les mécanismes d'AMF sont vulnérables à la force brute et qu'il est essentiel de communiquer les raisons du verrouillage du compte et de fournir aux utilisateurs des moyens accessibles de s'authentifier et de lever le verrouillage. Les exemples incluent l'appel d'un
ou en utilisant la vérification biométrique.
Mettre en œuvre un mécanisme de vérification de l'intégrité des transactions.
Si l'authentification garantit l'identité de l'utilisateur, elle n'élimine pas la possibilité d'activités frauduleuses au cours du processus de transaction. Les mécanismes de vérification de l'intégrité des transactions sont des fonctions de sécurité auxiliaires qui donnent aux utilisateurs le temps et les outils nécessaires pour réagir aux fraudes potentielles. La mise en œuvre d'un mécanisme de vérification de l'intégrité des transactions garantit que chaque transaction fait l'objet d'un examen approfondi afin de confirmer son exactitude et son authenticité.
Les développeurs peuvent mettre en œuvre les meilleures pratiques suivantes :
Lancer un appel de vérification/confirmation de la transaction.
Fournir un historique des transactions en temps réel.
Faire passer le temps de recharge de 12 à 24 heures.
Désactiver les transactions à l'étranger par défaut ; ne les autoriser que par l'intermédiaire de l'AMF.
Autorisation
Définir et valider les droits d'accès des utilisateurs aux ressources pertinentes de l'application.
Mettre en œuvre l'autorisation côté serveur.
L'autorisation côté serveur fait référence à la validation et à l'octroi de permissions d'accès aux utilisateurs ou aux applications par un serveur ou un serveur d'autorisation. Cela garantit que les décisions de contrôle d'accès et les autorisations sont gérées et appliquées côté serveur plutôt que côté client/par l'appareil. En mettant en œuvre l'autorisation côté serveur, les développeurs réduisent les possibilités pour les attaquants malveillants d'altérer ou de contourner les mesures de sécurité de l'application afin d'obtenir un accès non autorisé aux données sensibles (par exemple, les IIP et les données d'authentification).
Les développeurs doivent mettre en œuvre une autorisation côté serveur après une authentification réussie avant d'accorder des autorisations d'accès et s'assurer que les utilisateurs se voient accorder l'accès sur la base des éléments suivants :
Rôle assigné avec permissions: Veiller à ce que les utilisateurs ne puissent effectuer que des tâches relevant de leurs responsabilités.
Facteurs contextuels: Scénarios d'accès dynamiques tels que le temps d'accès et l'analyse comportementale.
Mettre en œuvre l'autorisation côté client par le biais de la liaison des appareils.
L'autorisation côté client (c'est-à-dire sur l'appareil) gère les permissions d'accès au sein d'une application mobile. Il s'agit d'une pratique risquée, car le fait de s'appuyer sur l'autorisation côté client peut exposer les applications à des vulnérabilités telles que l'accès non autorisé et la fraude potentielle.
Si les fonctions commerciales d'une application (par exemple, l'instanciation de jetons logiciels) requièrent des autorisations côté client, il est recommandé d'utiliser la liaison d'appareil (une pratique de sécurité qui associe des autorisations à des privilèges d'accès sur un appareil particulier). En mettant en œuvre la liaison d'appareil, les applications peuvent vérifier l'identité de l'appareil et établir la confiance. Cela réduit les risques associés aux accès non autorisés et maintient un chemin sécurisé et fiable entre les appareils, les applications et les serveurs. Les développeurs doivent établir une liaison entre les applications et l'appareil lorsque l'identité d'un utilisateur est utilisée pour la première fois sur un appareil mobile non enregistré et doivent également vérifier que les applications :
Vérifier si des modifications ont été apportées à l'appareil depuis la dernière exécution.
Vérifier si des modifications ont été apportées aux marqueurs d'identité de l'appareil.
Vérifiez que l'appareil sur lequel fonctionne l'application est sécurisé (par exemple, pas de jailbreaking ou de rooting).
Il ne s'agit là que de quelques exemples de techniques de meilleures pratiques utilisées par l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces techniques peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des meilleures pratiques les plus récentes de l'industrie pour vérifier les liaisons avec les appareils.
Pour vérifier un appareil Android, les développeurs peuvent
Obtenir des identifiants uniques tels que l'IMEI ou l'ID Android.
Récupérer les informations relatives à la construction.
Exploiter les fonctions de l'API native du système d'exploitation, telles que SafetyNet de Google.
Pour vérifier un appareil iOS, les développeurs peuvent :
Exploiter les services natifs du système d'exploitation, tels que l'identifiant d'appareil d'Apple, via UIDevice.
L'application informe les utilisateurs de toutes les autorisations requises avant qu'ils ne l'utilisent.
Les autorisations requises sont des droits et des capacités spécifiques que l'application demande à l'appareil mobile. Ces autorisations définissent les ressources ou les fonctionnalités auxquelles l'application peut accéder sur l'appareil de l'utilisateur. Parmi les exemples, citons notamment l'appareil photo, le microphone et la localisation.
En mettant en place des notifications appropriées qui informent les utilisateurs des autorisations demandées, les développeurs peuvent empêcher les utilisateurs d'accorder à leur insu des autorisations excessives, ce qui peut permettre à des acteurs malveillants d'exploiter des vulnérabilités et de voler des données sensibles (par exemple, des IPI et des données d'authentification). Ces notifications permettront également aux utilisateurs de prendre des décisions éclairées sur les applications qu'ils installent.
Les développeurs doivent :
Utilisez des alertes in-app pour demander l'autorisation d'accès aux utilisateurs.
Veillez à ce que les notifications/alertes n'affichent pas de données sensibles.
Ne demandez que les autorisations indispensables au fonctionnement de l'application.
L'application informe les utilisateurs de toutes les transactions à haut risque autorisées et effectuées.
Si une application dispose de fonctionnalités de transactions à haut risque, les utilisateurs doivent être avertis immédiatement lorsqu'une transaction a été autorisée et effectuée. En mettant en œuvre ce contrôle, les développeurs peuvent s'assurer que les utilisateurs sont informés immédiatement lorsque des transactions à haut risque ont été autorisées et effectuées, afin qu'ils puissent être en mesure d'identifier les transactions frauduleuses potentielles dès que possible.
Les développeurs doivent adopter les méthodes suivantes pour alerter un utilisateur :
Alertes dans l'application (In-App).
Notifications par courrier électronique.
Notifications par Short Message Service (SMS).
Les développeurs doivent également veiller à ce que les notifications/alertes n'affichent pas de données sensibles et ne demandent que les autorisations nécessaires au fonctionnement de l'application.
Il ne s'agit là que de quelques exemples de techniques de notification des meilleures pratiques utilisées par l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces techniques peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des meilleures pratiques les plus récentes du secteur pour notifier aux utilisateurs les transactions à haut risque autorisées et effectuées.
Stockage des données
Sauvegarde de l'intégrité et de la confidentialité des données sensibles dans l'appareil de l'utilisateur et le serveur de l'application.
L'application stocke des données sensibles qui ne sont nécessaires que pour les transactions.
Les données sensibles sont définies comme les données utilisateur (PII) et les données d'authentification (par exemple, les informations d'identification, les clés de cryptage). Les développeurs ne doivent stocker que les données sensibles nécessaires aux fonctions commerciales de l'application. L'accumulation d'informations inutiles augmente l'impact des failles de sécurité potentielles et fait d'une application une cible attrayante pour les acteurs malveillants.
En mettant en œuvre ce contrôle de sécurité, les développeurs peuvent s'assurer que l'exposition est limitée aux données requises pour des fonctions commerciales spécifiques, minimisant ainsi l'impact d'un accès non autorisé ou d'une violation de données.
Les développeurs doivent classer les données utilisées par l'application en fonction des niveaux de sensibilité de l'organisation et des exigences légales, et adopter les lignes directrices suivantes pour sécuriser les données classées comme sensibles :
Mettre en œuvre une solution de stockage sécurisée en fonction de sa sensibilité côté client/serveur.
Appliquer des mesures de protection des données (par exemple, tokenisation, hachage avec du sel, cryptage).
Supprimer les données sensibles lorsqu'elles ne sont plus nécessaires.
L'application met en œuvre un stockage sécurisé des données sensibles.
Le stockage sécurisé des applications mobiles consiste à mettre en œuvre des techniques et des pratiques pour protéger les données sensibles stockées sur les appareils mobiles et les serveurs d'applications contre l'accès non autorisé, le vol ou la falsification. Cela implique des bonnes pratiques telles que le cryptage, le hachage, la tokenisation et des contrôles d'accès appropriés. En mettant en œuvre un stockage sécurisé, les développeurs peuvent atténuer les risques d'accès non autorisé, de compromission des appareils, de violations et de fuites potentielles de données.
Les développeurs doivent mettre en œuvre une solution de stockage sécurisée qui soit proportionnelle à la sensibilité des données et doivent également établir l'ordre de priorité suivant pour une solution de stockage sécurisée (des données les plus sensibles aux données les moins sensibles) :
Côté serveur (toutes les données sensibles doivent être stockées côté serveur).
côté client, dans l'environnement d'exécution de confiance (si le côté serveur est impossible, stocker toutes les données sensibles dans l'environnement d'exécution de confiance côté client).
L'application stocke les données sensibles en toute sécurité côté serveur.
Le stockage de données sensibles côté serveur consiste à stocker les données sur des serveurs d'applications ou des bases de données distants. Cette approche crée un meilleur environnement pour protéger les données contre les accès non autorisés ou les violations, en permettant un contrôle d'accès plus sécurisé, des options pour mettre en œuvre de meilleures mesures de sécurité telles qu'un cryptage plus complexe, et des dispositions pour des mises à jour de sécurité plus rapides.
En mettant en œuvre le stockage des données sensibles côté serveur, les développeurs peuvent atténuer les risques inhérents au stockage des données côté client, car le stockage côté client est intrinsèquement plus sensible aux techniques d'exploitation du stockage des données couramment utilisées par les acteurs malveillants dans les escroqueries mobiles.
Les développeurs doivent appliquer au moins une des mesures de protection des données suivantes :
Pour les mots de passe uniquement, les développeurs peuvent utiliser le hachage avec sel (le hachage avec sel est utilisé pour ajouter une couche supplémentaire de sécurité en rendant le calcul intensif pour les attaquants).
Déchiffrer les données sensibles originales. Dans le contexte du stockage de mots de passe ou de la dérivation de clés, les développeurs devraient utiliser des fonctions de dérivation de clés à sens unique ou des algorithmes de hachage lents, tels que PBKDF2, bcrypt ou script). Au lieu de stocker des mots de passe réels, des sels uniques sont générés et combinés avec les mots de passe, créant ainsi des hachages salés.
Les développeurs peuvent crypter les données sensibles à l'aide de normes de cryptage telles que AES-128.
Les développeurs peuvent mettre en œuvre la tokenisation avec une tokenisation autogérée ou un service de tokenisation, en remplaçant les données sensibles par des tokens lorsque c'est possible. En outre, les développeurs doivent s'assurer que la tokenisation est suffisamment longue et complexe (soutenue par une cryptographie sécurisée) en fonction de la sensibilité des données et des besoins de l'entreprise.
Il ne s'agit là que de quelques exemples de bonnes pratiques du secteur. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces meilleures pratiques peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des meilleures pratiques les plus récentes pour stocker les données sensibles en toute sécurité sur le serveur.
L'application stocke les données sensibles en toute sécurité côté client dans un environnement d'exécution de confiance (TEE).
L'environnement d'exécution de confiance (TEE) est une zone isolée au sein de l'architecture matérielle ou du processeur d'un appareil mobile qui fournit un environnement hautement sécurisé pour le stockage de données sensibles et l'exécution d'opérations sensibles ou critiques. Il protège les données sensibles, les clés cryptographiques et les processus critiques contre tout accès non autorisé ou toute altération. Si les fonctions commerciales d'une application nécessitent un stockage sensible côté client, celui-ci doit être stocké dans le TEE de l'appareil.
Les développeurs peuvent atténuer les menaces provenant d'un appareil compromis et d'acteurs malveillants externes en stockant correctement les données sensibles dans le TEE côté client. Ce stockage peut également réduire l'accès non autorisé aux données sensibles d'un utilisateur sur une application et empêcher le vol des clés de chiffrement.
Les développeurs doivent stocker les données sensibles de manière sécurisée côté client dans un environnement d'exécution de confiance (TEE) tel que la TrustZone d'ARM d'Android et la Secure Enclave d'Apple. Les développeurs doivent également stocker au minimum la liste suivante de données sensibles dans un TEE :
Identifiants biométriques.
Jetons d'authentification.
Clés cryptographiques dans un système de gestion de clés sécurisé tel que Android Keystore ou iOS Keychain.
Les exemples ci-dessus sont des données sensibles que les développeurs doivent stocker dans le TEE. Au fur et à mesure de l'évolution de l'écosystème des appareils mobiles, les développeurs devraient être en mesure de stocker toutes les données nécessaires dans le TEE.
Les développeurs peuvent envisager d'utiliser des TEE virtualisés pour les appareils dépourvus de TEE matériel. Les développeurs peuvent également désactiver l'application ou ses fonctions de transaction à haut risque, car l'application est considérée comme non sécurisée pour les transactions à haut risque.
L'application supprime les données sensibles lorsqu'elles ne sont plus nécessaires.
L'effacement des données sensibles consiste à supprimer ou à effacer définitivement les données confidentielles, privées ou sensibles des dispositifs de stockage, des serveurs ou des bases de données. Ce processus garantit que les données sensibles sont irrémédiablement supprimées et qu'elles ne peuvent pas être consultées, récupérées, exposées accidentellement ou reconstituées par des personnes non autorisées ou par des méthodes de récupération des données.
En mettant en œuvre ce processus, les développeurs peuvent minimiser la fenêtre dans laquelle les attaquants peuvent exploiter les vulnérabilités pour voler des données sensibles. Les développeurs doivent utiliser les techniques de sécurité du stockage persistant suivantes :
Effacer les cookies stockés à la fin de l'application ou utiliser le stockage des cookies en mémoire.
Supprimez toutes les données sensibles lors de la désinstallation de l'application.
Lorsque les fonctions commerciales connexes cessent, supprimez manuellement du système de fichiers tous les fichiers de base de données contenant des données sensibles (par exemple, les caches iOS WebView).
Il ne s'agit là que de quelques exemples des meilleures pratiques de l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces techniques peuvent devenir obsolètes. C'est pourquoi les développeurs doivent se tenir au courant des meilleures pratiques les plus récentes de l'industrie pour supprimer les données sensibles lorsqu'elles ne sont plus nécessaires.
Anti-fraude et anti-retournement
Mettre en œuvre des mesures pour éviter que l'application ne soit altérée ou compromise. Il peut s'agir, par exemple, d'un antivirus ou d'une protection contre la surveillance et l'espionnage du clavier.
L'application est signée par des certificats provenant de magasins d'applications officiels.
Les applications sont souvent usurpées par des acteurs malveillants et distribuées par des canaux moins strictement réglementés. La signature d'une application à l'aide de certificats fournis par les magasins d'applications officiels garantit au système d'exploitation mobile et aux utilisateurs que l'application mobile est vérifiée.
La mise en œuvre de la signature du code permet aux systèmes d'exploitation de déterminer s'ils autorisent l'exécution ou l'installation d'un logiciel en fonction des signatures ou des certificats utilisés pour signer le code. Cela permet d'éviter l'installation et l'exécution d'applications potentiellement dangereuses. En outre, la signature du code contribue également à la vérification de l'intégrité, car les signatures changent si l'application a été altérée.
Les développeurs doivent signer leurs applications à l'aide de certificats. Cette section fournit des exemples de la manière de procéder pour les deux plateformes les plus populaires, iOS et Android. Pour l'App Store d'Apple, il suffit de s'inscrire à l'Apple Developer Programme et de créer un compte
dans le portail des développeurs. Les développeurs peuvent s'inscrire à l'Apple Developer Programme et peuvent se référer au guide du développeur suivant pour la signature de code sous la rubrique "choses à noter". Pour Android, il existe plusieurs magasins d'applications. Pour le Play Store de Google, il est possible de configurer Play App Signing, qui est une exigence pour la distribution via le Play Store de Google.
L'application met en œuvre la détection de jailbreak ou de root.
Les appareils rootés et jailbreakés sont généralement considérés comme peu sûrs. Ils permettent aux utilisateurs d'obtenir des privilèges élevés, ce qui facilite le contournement des limites de sécurité et du système d'exploitation. Ces privilèges élevés peuvent être dangereux pour les applications, car ils permettent à des acteurs malveillants d'exploiter des vulnérabilités, de voler des informations d'identification, de prendre le contrôle des appareils des utilisateurs et d'effectuer des transactions frauduleuses dans les applications.
En mettant en place une détection de jailbreak ou de root, les développeurs peuvent empêcher les exploits susmentionnés de se produire, protéger la propriété intellectuelle des applications, garantir la stabilité des applications et empêcher le contournement des systèmes in-app.
Détection de jailbreak ou de racine pour Android :
Vérifier la présence d'un superutilisateur ou d'un binaire SU.
Détecter les modifications du système de fichiers racine.
Recherchez des applications rootées.
Vérifier la présence d'une récupération personnalisée.
Vérifier si l'utilisation de l'API n'est pas sûre.
iOS jailbreak ou détection de racine :
Détecter l'utilisation d'API restreintes.
Cherchez des astuces de jailbreak comme les mods.
Recherchez les boutiques d'applications non officielles, par exemple, vérifiez la signature de la boutique d'applications Cydia.
Recherchez les modifications du noyau.
Vérifier l'intégrité des systèmes de fichiers critiques.
Utiliser des bibliothèques tierces conçues pour détecter la falsification des appareils.
Il ne s'agit là que de quelques exemples de contrôles de bonnes pratiques utilisés par l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces contrôles peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des dernières bonnes pratiques du secteur pour mettre en œuvre la détection du jailbreak ou de l'enracinement.
L'application met en œuvre la détection des émulateurs.
Les émulateurs sont des logiciels utilisés pour tester les applications mobiles. Ils permettent aux utilisateurs de tester une application mobile sur différents appareils et versions mobiles imités. Bien qu'utiles pour les tests, les applications ne doivent pas être montées sur des émulateurs en dehors de l'environnement de développement.
En mettant en œuvre la détection de l'émulation, les développeurs peuvent empêcher les acteurs malveillants d'effectuer des analyses dynamiques, des opérations de rootage, de débogage, d'instrumentation, de hooking et de fuzz testing sur un appareil émulé qu'ils peuvent contrôler. Ce faisant, les développeurs peuvent empêcher les acteurs malveillants de découvrir des vulnérabilités au sein de l'application en vue de les exploiter.
Les développeurs doivent mettre en œuvre la stratégie de détection suivante pour identifier les caractéristiques des solutions d'émulation couramment utilisées. Voici quelques recommandations sur les éléments à vérifier :
Vérifier l'utilisation de la batterie.
Vérifier les horodatages et les horloges.
Vérifier les comportements multi-touch.
Vérifier la mémoire et l'analyse des performances.
Effectuer des vérifications sur le réseau.
Vérifiez s'il s'agit d'un problème matériel.
Vérifiez sur quoi est basé le système d'exploitation.
Vérifier les empreintes digitales de l'appareil.
Vérifier les configurations de construction.
Vérifier la présence de services et d'applications d'émulation.
Il ne s'agit là que de quelques exemples de contrôles de bonnes pratiques utilisés par l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces contrôles peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des meilleures pratiques les plus récentes de l'industrie pour la mise en œuvre de la détection des émulateurs.
L'application met en œuvre une détection anti-malware.
Les acteurs malveillants utilisent de plus en plus les applications malveillantes comme vecteur pour compromettre les appareils mobiles des utilisateurs. Ces applications offrent aux utilisateurs la commodité nécessaire pour effectuer des transactions quotidiennes. Les applications malveillantes utilisent principalement des fonctions de chargement latéral pour amener les utilisateurs à installer des logiciels malveillants sur leurs appareils.
En mettant en œuvre des capacités de détection des logiciels malveillants sur une application au moment de l'exécution, les développeurs peuvent empêcher les utilisateurs d'être exploités par des logiciels malveillants qui exploitent les vulnérabilités de l'application et du système d'exploitation, volent les informations d'identification, prennent le contrôle de l'appareil et exécutent des transactions frauduleuses. Les développeurs doivent mettre en œuvre des capacités de détection des logiciels malveillants dans leurs applications. Cela peut se faire de différentes manières, mais pas uniquement :
Intégrer un kit de développement logiciel (SDK) Runtime-Application-Self-Protection (RASP) dans leurs applications.
Utiliser les SDK RASP pour vérifier et détecter les applications malveillantes au moment de l'exécution.
Vérifier et prévenir les chevauchements.
Prévenir le détournement de clics.
Empêcher le crochetage de la mémoire de l'application.
Il ne s'agit là que de quelques exemples de contrôles de bonnes pratiques utilisés par l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces contrôles peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des meilleures pratiques les plus récentes de l'industrie pour mettre en œuvre la détection des logiciels malveillants.
Si un acte malveillant est détecté, les développeurs doivent désactiver l'application, fournir à l'utilisateur les informations nécessaires sur les raisons de cette désactivation et l'inviter à désinstaller la ou les applications malveillantes de son appareil. Ils peuvent également avertir l'utilisateur et désactiver les fonctions à haut risque de l'application jusqu'à ce que l'utilisateur ait remédié à la ou aux applications malveillantes.
L'application met en œuvre des mécanismes anti-crochetage.
Le hooking est une technique utilisée par les attaquants pour intercepter ou modifier le comportement d'une application mobile au moment de l'exécution. Il s'agit d'insérer ou de s'accrocher au flux d'exécution d'une application pour surveiller ses activités, modifier son comportement, injecter du code malveillant ou modifier les fonctions du code existant afin d'exploiter les vulnérabilités.
En mettant en œuvre des mécanismes anti-hooking sur les applications, les développeurs peuvent empêcher les attaques susmentionnées de se produire et empêcher les accès non autorisés, protéger les opérations de transaction à haut risque, détecter et empêcher les tentatives d'altération et de modification, préserver la propriété intellectuelle et maintenir la fiabilité de l'application. Les développeurs devraient mettre en œuvre les exemples de mécanismes suivants pour atténuer les attaques de type "hooking" :
Mettre en place des protections pour bloquer les injections de code.
Mettre en œuvre des protections pour empêcher le crochetage de méthodes en empêchant les modifications du code source de l'application (à la fois sur le client et le serveur).
Mettez en place des protections pour empêcher l'exécution de codes modifiés dans votre application.
Mettez en place des protections pour empêcher l'accès à la mémoire et la manipulation de la mémoire de votre application.
Mettre en œuvre des algorithmes résistants à la falsification ou des kits de développement logiciel (SDK) anti-fraude (communément appelés Runtime-Application-Self-Protection SDK).
Vérifier la présence de paramètres non sécurisés, tels que des API et des paramètres obsolètes.
Il ne s'agit là que de quelques exemples de contrôles de bonnes pratiques utilisés par l'industrie. Au fur et à mesure que l'écosystème des appareils mobiles évolue, ces contrôles peuvent devenir obsolètes. Les développeurs doivent donc se tenir au courant des meilleures pratiques les plus récentes de l'industrie pour mettre en œuvre des mécanismes anti-crochetage.
L'application met en œuvre des contre-mesures de superposition, de visualisation à distance et de capture d'écran.
Des informations sensibles peuvent être capturées ou enregistrées sans le consentement explicite de l'utilisateur lorsqu'une application dispose de fonctionnalités d'enregistrement d'écran, de capture d'écran ou de superposition. Par exemple :
Les attaques par superposition trompent les utilisateurs en créant une fausse couche imitant les applications de confiance, dans le but de voler des données sensibles.
Les attaques par visionnage à distance impliquent un accès non autorisé à l'écran d'un appareil, ce qui permet aux pirates d'obtenir des données sensibles à distance.
Les attaques par capture d'écran se produisent lorsque des acteurs malveillants capturent l'écran d'un appareil sans le consentement de l'utilisateur et en extraient des données sensibles.
La mise en œuvre de contre-mesures en matière de superposition, de visualisation à distance et de capture d'écran peut garantir la sécurité des informations sensibles, le respect de la vie privée des utilisateurs et la protection des données sensibles contre la perte ou l'utilisation abusive par inadvertance.
Les développeurs doivent mettre en œuvre des contrôles anti-tampering et anti-malware via les SDK RASP afin d'empêcher les applications malveillantes d'utiliser des superpositions et des exploits de visualisation à distance.
Pour les captures d'écran, les développeurs peuvent utiliser l'indicateur FLAG_SECURE pour les applications Android et des indicateurs similaires pour iOS afin de bloquer toutes les capacités de capture d'écran lors de l'utilisation de l'application. Cependant, il est possible que des fonctions commerciales nécessitent des capacités de capture d'écran (par exemple, prendre une capture d'écran d'une transaction bancaire terminée). Dans ce cas, il est recommandé de désactiver les fonctions de capture d'écran pour les écrans ou les pages qui contiennent des données sensibles (IIP et données d'authentification). Les développeurs peuvent également envisager de masquer les entrées contenant des données sensibles et les écrans des capteurs lorsque l'application est en arrière-plan.
Les pages de connexion, les pages d'authentification multifactorielle, les justificatifs de sécurité et les pages de modification des informations personnelles sont autant d'exemples d'endroits où il est possible de désactiver ces capacités de capture d'écran, sans toutefois s'y limiter.
L'application met en œuvre la capture anti-keystroke ou anti-keylogger contre les claviers virtuels tiers sur les appareils Android.
La capture et l'enregistrement des frappes sont des méthodes utilisées par des acteurs malveillants pour surveiller, consigner et enregistrer les touches pressées sur un clavier à l'insu et sans le consentement de l'utilisateur. Cela permet d'enregistrer et de capturer des données potentiellement sensibles (par exemple, des informations confidentielles et des données d'authentification).
En mettant en place un clavier intégré, les développeurs peuvent contrôler la destination des données d'enregistrement et réduire le risque que des claviers virtuels tiers non sécurisés agissent comme des enregistreurs de frappe pour capturer les frappes.
Outre l'utilisation de claviers intégrés aux applications, les développeurs devraient mettre en œuvre les suggestions suivantes pour les entrées qui nécessitent des données sensibles (par exemple, les IIP et les données d'authentification) : Désactiver la correction automatique, le remplissage automatique, la suggestion automatique, le couper, le copier et le coller pour les fonctions ou les applications qui contiennent des données sensibles. Parmi les tâches qui devraient utiliser des claviers intégrés, citons la connexion, la saisie d'un OTP ou d'autres facteurs de vérification.
