6 pièce(s) jointe(s)
Nombreux sont les développeurs d'applications sur iOS qui prennent des raccourcis en matière de sécurité
Nombreux sont les développeurs d'applications sur iOS qui prennent des raccourcis en matière de sécurité,
d'après une étude
Bien qu’Apple exige que les développeurs intègrent le chiffrement de bout en bout à leurs applications, une étude suggère qu’un grand nombre d’entre eux ne le font pas. Apple propose même une fonctionnalité qui aide les développeurs à se conformer aux exigences de confidentialité des données, et les données de la société de sécurité mobile Wandera, qui a mené l’étude, montrent que cette fonctionnalité n’est pas utilisée correctement.
Pour comprendre comment les développeurs d’applications utilisent (ou n’utilisent pas) le chiffrement, Wandera a analysé plus de 30 000 des applications iOS les plus couramment utilisées par les employés. La société a également constaté que plus des deux tiers des applications n’utilisaient pas cette fonctionnalité pour chiffrer des données.
Pourquoi un développeur d'applications voudrait-il utiliser le chiffrement des données ?
Le chiffrement des données améliore la confidentialité et l'intégrité des utilisateurs, en protégeant leurs données des attaques de tiers. Il joue un rôle important dans la sécurité et la confidentialité en réduisant la visibilité du trafic pour tous ceux qui pourraient le surveiller. Cela permet aux utilisateurs d'envoyer des informations sensibles, telles que des noms d'utilisateur et des mots de passe ou des informations de carte de crédit, sur Internet, sans que celles-ci ne soient découvertes par un pirate informatique.
Dans le cas d’une application susceptible de faire fuiter des données, c’est-à-dire une application qui n’utilise pas de chiffrement, un pirate informatique sur le même réseau peut détecter le trafic et obtenir les données en transit. Et les applications qui font fuiter les données sont plus courantes que l’on ne pourrait le penser.
Sur les plateformes Apple, une fonctionnalité de sécurité réseau appelée App Transport Security (ATS) est disponible et activée par défaut. ATS est fondamentalement un ensemble de règles garantissant que les applications iOS et leurs extensions se connectent aux services Web à l'aide de protocoles de connexion sécurisés.
En 2015, Apple a lancé ATS en tant que fonctionnalité optionnelle avec l'arrivée de iOS 9.0. En 2016, lors de la WWDC (Worldwide Developers Conference), Apple a annoncé que toutes les applications iOS seraient tenues de suivre et d'utiliser ATS d'ici janvier 2017, à moins qu'une justification solide soit fournie pour les exceptions énumérées. Cependant, Apple a reporté cette date limite indéfiniment.
Pourquoi un développeur d'applications choisirait-il de ne pas chiffrer les données ?
Les directives de révision des applications indiquent actuellement que les développeurs doivent fournir une justification pour désactiver ATS. Mais selon plusieurs sources, ainsi que les recherches de Wandera, il semble que la justification n'ait pas besoin d'être forte et, dans la plupart des cas, les développeurs désactivent avec succès ATS.
Les développeurs d'applications peuvent avoir de bonnes raisons de désactiver ATS. Les applications communiquent avec des services tiers de publicité, d’études de marché, d’analyse et d’hébergement de fichiers. Ces services externes peuvent ne pas prendre en charge les connexions HTTPS. Les réseaux de publicité tels que MoPub et Google AdMob recommandent de désactiver complètement ATS afin de garantir le chargement correct des annonces.
ATS - exceptions globales
À l'origine, les développeurs pouvaient complètement désactiver ou activer ATS. Mais dans les versions iOS plus récentes (à partir de iOS 10), la granularité est plus large, les développeurs peuvent donc définir une configuration ATS globale, puis l'exclure au cas par cas pour des fonctions spécifiques au sein d'une application, telles que lors de la récupération de contenu multimédia. La définition de règles plus détaillées remplace la configuration ATS globale pour ces exceptions.
Utilisation d'ATS dans des applications payantes ou gratuites
Les infrastructures publicitaires nécessitent souvent la désactivation d'ATS dans une certaine mesure. Il n'est donc pas surprenant que les applications payantes (qui ne diffusent généralement pas d'annonces) aient des paramètres ATS plus stricts.
Les opérateurs de réseaux publicitaires évoluent dans un espace concurrentiel et souhaitent rationaliser le processus permettant aux développeurs de rendre leurs applications compatibles. En supprimant les « obstacles » tels que les exigences en matière de chiffrement, il est plus facile pour un plus grand nombre de développeurs d’intégrer leurs réseaux publicitaires dans leurs applications.
Sur les applications payantes, ATS est globalement activé plus souvent
Selon les recherches de l’entreprise, un pourcentage élevé (45,7%) des applications payantes sont compatibles ATS dans le monde entier. Pendant ce temps, la grande majorité (68,5%) des applications gratuites ont complètement désactivé ATS.
Configuration globale ATS par catégorie d'application
La configuration globale ATS ne diffère que légèrement selon les catégories, les finances étant en tête du peloton. Cependant, même pour les principales applications financières, seul un tiers d'entre elles disposent de la fonctionnalité ATS au niveau mondial et nombre d'entre elles possèdent encore des domaines d'exception globaux.
Même si elles ne sont pas incluses dans le données ci-dessous, l’étude pensent que les applications d’autocollants (stickers) méritent néanmoins d'être mentionnées. Il s’agit notamment d’applications fournissant des autocollants pour iMessage. Dans son analyse, la société a découvert que presque toutes les applications d'autocollants (96,8%) activent ATS au niveau mondial. Bien qu’elle ne sait pas pourquoi, elle estime qu’il n’est pas risqué d’affirmer que la plupart des applications d’autocollants n’ont aucune raison de communiquer avec le Web extérieur, et donc que les développeurs n’ont donc pas besoin de modifier les paramètres ATS, laissant ATS activé par défaut.
ATS - exceptions de domaine
En plus de répertorier les exceptions globales, le développeur peut également spécifier des exceptions pour chaque domaine. Cette configuration remplace complètement les paramètres globaux d'un domaine particulier. L'exception de domaine peut donc fonctionner à la fois comme une liste blanche et une liste noire, en fonction de la configuration globale.
Plus des deux tiers (70%) des applications ne possèdent aucun domaine d'exception et les 30% restants en ont moins de cinq. Remarque: les applications avec plus de 20 domaines d'exception ont été exclues car elles étaient très peu nombreuses.
Pièce jointe 481833
La plupart des applications n'ont aucun domaine d'exception (les applications avec plus de 20 domaines d'exception sont exclues)
Une exception de domaine peut en fait signifier l'activation et la désactivation d'ATS. Le graphique ci-dessous indique si chaque entrée de domaine active ou désactive ATS pour les applications avec ATS désactivé globalement.
Plus des trois quarts des applications pour lesquelles ATS est globalement désactivé (77,3%) ne spécifient aucun domaine d'exception. Par conséquent, les protections sont complètement désactivées pour toutes les communications réseau.
Une petite partie (9,4%) des applications pour lesquelles ATS est globalement désactivé spécifient des exceptions permettant d'activer ATS. Bien que l'approche inverse soit généralement une meilleure pratique (activer globalement, puis désactiver pour quelques domaines d'exception), il s'agit toujours d'une configuration judicieuse.
Cependant, pour certains, la configuration n’a aucun sens, comme dans le cas des 9.2% qui spécifient des domaines d’exception pour désactiver ATS. Cela laisse supposer que les développeurs pourraient ne pas comprendre ATS et ne l’utiliser donc pas comme prévu par Apple en désactivant ATS globalement et en répertoriant les domaines d’exception pour désactiver ATS.
Pour chaque domaine d’exception, trois exceptions ATS possibles peuvent être spécifiées: autoriser les chargements HTTP, désactiver le forward secrecy et autoriser le chargement.de versions obsolètes de TLS. Parmi ces entrées d’exception de domaine, la clé d’exception la plus courante est la clé «autoriser les chargements HTTP».
Selon le rapport, « Peut-être la raison pour laquelle de nombreux développeurs désactivent ATS, malgré les efforts d'Apple, est qu'ils ne comprennent pas vraiment comment cela fonctionne en raison de sa complexité. Ou peut-être trouvent-ils une solution de facilité en soumettant simplement tous les domaines dont leurs applications ont besoin comme exceptions pour éviter toute interruption potentielle de l'expérience de l'utilisateur final en raison d'une incompatibilité avec les serveurs ».
Source : rapport
Voir aussi :
:fleche: La CNIL inflige une amende de 400 000 € à une société immobilière, pour atteinte à la sécurité des données et non-respect des durées de conservation
:fleche: Cinq raisons pour lesquelles votre organisation doit adopter une architecture de sécurité zéro confiance, par Forrester Research
:fleche: Des développeurs iOS lancent des poursuites contre Apple pour abus de position dominante, et demandent l'ouverture d'iOS à des stores alternatifs
:fleche: Des applications iOS tierces partagent les données d'utilisateurs d'iPhone avec des trackers, des sociétés de marketing et des sociétés de recherche
