EXIGENCES TECHNIQUES DE SECURITE

Transcription

1 EXIGENCES TECHNIQUES DE SECURITE DEVELOPPEMENT D'APPLICATIONS ANDROID ET IOS MARDI 9 JUIN VERSION 1.1 VERSION : RÉF. : ######################

2 SOMMAIRE Contenu DEFINITIONS 4 EXIGENCES TECHNIQUES DE SECURITE PERMISSIONS 5 COMMON-PERM Restreindre les permissions de l'application au strict nécessaire 5 ANDROID-PERM-NEW Créer de nouvelles permissions avec précaution STOCKAGE DES DONNEES 6 COMMON-STORAGE Stocker les informations sensibles sur l équipement uniquement si absolument nécessaire 6 COMMON-CRYPT Chiffrer les données sensibles stockées sur l équipement 6 ANDROID-EXT-STORAGE Sécuriser l utilisation du stockage externe 7 COMMON-LOGS Ne pas envoyer d'informations sensibles dans les logs 8 COMMON-PWDCODE Ne pas stocker d'informations sensibles dans le code de l'application 8 COMMON-SQLITE Ne pas stocker d'informations sensibles dans les bases de données SQLite 8 IOS-APP-PLIST Ne pas stocker d'informations sensibles dans des fichiers PLIST 9 IOS-APP-COREDATA Ne pas stocker d'informations sensibles dans les services CoreData 9 IOS-APP-NSURLCACHE Ne pas stocker d'informations sensibles dans le cache des requêtes HTTP 9 ANDROID- PROVIDER-PERM Restreindre les permissions sur les Content Providers au strict nécessaire 10 COMMON-PARAM-QUERY Utiliser les méthodes paramétrées pour interroger un content provider BACKEND ET UTILISATION DU RESEAU 10 COMMON-AUTH Authentification et autorisation doivent être décidées du côté d un backend 11 COMMON-TLS Chiffrer les échanges sur le réseau 11 ANDROID-IPC-NETWORK Ne pas utiliser le réseau pour des échanges entre applications sur le même équipement 12 COMMON-CRT Utiliser un certificat de chiffrement valide et vérifier sa validité 12 2/17

3 COMMON-INPUT-VALIDATION Valider toutes les entrées sur l application (backend ou application mobile) 13 ANDROID-SMS Ne pas utiliser les SMS pour envoyer des messages à l application ANTI-PIRATAGE ET BONNES PRATIQUES DE DEVELOPPEMENT 14 ANDROID-WEBVIEW Sécuriser l utilisation des WebView 14 COMMON-FILES Ne pas laisser de fichiers inutiles dans le répertoire de l'application 15 COMMON-UDID Ne pas utiliser les identifiants uniques de l équipement 15 COMMON-CRYPTO Utiliser des moyens cryptographiques robustes 15 IOS-APP-SCHEME Filtrer les entrées par une URL scheme 16 IOS-APP-ENCRYPT Chiffrer l'application pour sa distribution dans un store 16 3/17

4 DEFINITIONS Information sensible NFOS SENSIBLES Ce tag est positionné dans le document lorsque l exigence s applique dans le cadre du traitement d une information sensible (au sens de la définition du RA00110). Équipement Appareil mobile ou non, équipé d une interface graphique ou non, capable d établir des échanges d informations avec d autres équipements au moyen de liaisons réseau (ex : Bluetooth, WiFi, ). Exemples d équipement : téléphone, smartphone, tablette, phablette, ordinateur portable, objet connecté Backend Services interrogés au moyen de liaisons réseau pour récupérer ou traiter les informations de l application mobile (ex : webservices, API, ). 4/17

5 EXIGENCES TECHNIQUES DE SECURITE 1.1 PERMISSIONS Android et ios utilisent des mécanismes de sandboxes 1 qui permettent de cloisonner les applications entre elles. Ainsi chaque application doit partager explicitement ses ressources et ses données (si nécessaire). COMMON-PERM Restreindre les permissions de l'application au strict nécessaire Le principe sécurité de moindre privilège doit s appliquer. L application ne doit demander que les permissions qui lui sont vraiment nécessaires. Il faut par ailleurs porter une attention particulière aux permissions sensibles (exemples : envoi de SMS, position GPS, ). Cette exigence permet : + de réduire les risques d utilisation d une permission par inadvertance ; + de limiter les permissions et de favoriser l adoption de l application par les utilisateurs ; + de limiter les impacts en cas d exploitation d une vulnérabilité par un attaquant. + Android Security Tips Requesting Permissions 2 + ios Accessing user data 3 ANDROID-PERM-NEW Créer de nouvelles permissions avec précaution La plupart des permissions Android définies par le système suffisent à couvrir toutes les situations. Si une nouvelle permission est absolument nécessaire, il faut d abord considérer le niveau de protection par signature. Le mécanisme de signature permet de rester transparent vis-à-vis de l utilisateur et permet de donner l autorisation uniquement aux applications signées par le même développeur, sans nécessité la création d une nouvelle permission. + Android Security Tips Creating Permissions 4 1 Sandbox : Android possède des mécanismes de sécurité qui permettent d isoler les données d une application et son exécution de code des autres applications ervices.html 4 5/17

6 1.2 STOCKAGE DES DONNEES Le stockage d informations sensibles est un des principaux enjeux de la sécurité d une application mobile. Plusieurs scénarios de risques sont à prendre en compte dans le cadre de la protection des informations sensibles : + Équipement volé ou perdu ; + Application tierce malveillante cherchant à accéder aux données des autres applications ; + Utilisateur malveillant analysant le contenu de son équipement et de ses applications. COMMON-STORAGE Stocker les informations sensibles sur l équipement uniquement si absolument nécessaire Les informations sensibles peuvent être récupérées sur des backends et affichées à l utilisateur. En revanche, le stockage d informations sensibles sur l équipement en lui-même ne doit être mis en œuvre que si c est absolument nécessaire (par exemple dans le cadre d applications devant fonctionner sans connexion réseau). Dans le cas d une absolue nécessité, il faudra envisager le chiffrement des données (voir COMMON-CRYPT ). COMMON-CRYPT Chiffrer les données sensibles stockées sur l équipement Si le stockage d informations sensibles est absolument nécessaire (voir COMMON- STORAGE), plusieurs solutions sont envisageables. Le type de solution de chiffrement à utiliser dépend du type d informations sensibles à stocker sur l équipement. 1. Petite quantité d informations sensibles Dans le cadre de petites quantités d informations sensibles, telles que des identifiants d authentification, des jetons de session, des clefs de chiffrement, etc., le conteneur sécurisé de l équipement peut être utilisé : KeyStore : Keychain : inservconcepts/02concepts/concepts.html#//apple_ref/doc/uid/tp CH204-TP9 6/17

7 2. Informations sensibles concernant l utilisateur de l équipement Pour sécuriser un nombre plus important d informations sensibles concernant l utilisateur de l équipement, les mécanismes de protection fournis par le système d exploitation peuvent être mis en œuvre. 3. Informations sensibles ne concernant pas l utilisateur de l équipement Si l application nécessite absolument de stocker des informations sensibles (par exemple, des données métier confidentielles), il faut étudier l utilisation d un conteneur de chiffrement tiers, autre que les conteneurs fournis par les systèmes d exploitation. Ces derniers sont vulnérables à des faiblesses inhérentes à l utilisation du code PIN ou du mot de passe de déverrouillage de l équipement (qui peut être compromis par de multiples biais). Android Security Tips Using internal storage 5 OWASP ios Developer Cheat Sheet Insecure Data Storage (M1) 6 ANDROID-EXT-STORAGE Sécuriser l utilisation du stockage externe Certains téléphones sous Android peuvent permettre l ajout de cartes SD. Les données sur le stockage externe (carte SD) sont accessibles en lecture et écriture par tout le monde (et par toutes les applications). Par ailleurs, la carte SD est un support amovible qui peut être dissocié de l équipement, lu et modifié sans aucun contrôle de sécurité de la part de l application. C est pourquoi aucune donnée sensible ne doit être enregistrée sur le stockage externe, même de manière chiffrée. Elles doivent être stockées dans le répertoire personnel de l application sur lequel de plus fortes permissions seront en place. Par ailleurs, il est important d effectuer une vérification sécurité de toutes les données qui proviennent d un stockage externe. Pour Android, cette exigence induit entre autres les points suivants : - Ne pas stocker d exécutables ou de fichiers Class sur la carte SD - Signer et vérifier les empreintes des fichiers qui doivent être chargés dynamiquement Android Security Tips Using internal storage 7 Android Security Tips Using external storage /17

8 OWASP ios Develope r Cheat Sheet Insecure Data Storage (M1) 9 COMMON-LOGS Ne pas envoyer d'informations sensibles dans les logs Les logs de l application ne doivent pas contenir d informations sensibles, tels que les mots de passe des utilisateurs lors de leur authentification sur l application. Il est à noter que les logs sont une ressource partagée sur Android. Toutes les applications possédant la permission READ_LOGS peuvent lire les logs. Android Security Tips Handling User Data 10 OWASP ios Developer Cheat Sheet Insecure Data Storage (M1) 11 COMMON-PWDCODE Ne pas stocker d'informations sensibles dans le code de l'application Les mots de passe stockés dans le code de l'application peuvent se retrouver dans l'application fournie sur le Store. D une manière générale, il ne faut pas stocker de mots de passe ou de clefs d authentification ou de chiffrement directement accessibles à l application. Même si l application est compilée, toutes les variables définies dans le code source peuvent être retrouvées dans l application distribuée. Voir l exigence COMMON-CRYPT pour plus de détails. COMMON-SQLITE Ne pas stocker d'informations sensibles dans les bases de données SQLite En ayant accès à l équipement, les bases de données SQLite peuvent être facilement lues par un client approprié disponible librement sur Internet. En particulier, les identifiants et les tokens d'authentification ne doivent pas être stockés dans une base de données SQLite /17

9 IOS-APP-PLIST Ne pas stocker d'informations sensibles dans des fichiers PLIST En ayant accès au téléphone, les fichiers PLIST peuvent être facilement lus. Il est primordial de n'enregistrer aucune information sensible telle que des identifiants ou des tokens d'authentification. Cette préconisation est valable pour les NSUserDefaults (stockées dans un fichier PLIST). Dans tous les cas, il est préférable de ne stocker aucune information sensible sur le téléphone. Si de telles informations doivent absolument être conservées sur le téléphone, le keychain doit être utilisé. OWASP ios Developer Cheat Sheet Insecure Data Storage (M1) 12 Property Lists Are Vulnerable 13 How not to store Passwords in ios 14 IOS-APP-COREDATA Ne pas stocker d'informations sensibles dans les services CoreData Les services CoreData sont une fonctionnalité pour le développement d'applications ios permettant entre autres d'avoir des relations entre les objets. Si une telle fonctionnalité est utilisée, il est primordial de ne stocker aucune information sensible dans ces CoreData. Les données de cette fonctionnalité sont stockées dans une base de données SQLite et sont donc facilement accessibles en ayant accès au téléphone (cf. COMMON-SQLITE). IOS-APP-NSURLCACHE Ne pas stocker d'informations sensibles dans le cache des requêtes HTTP Par défaut, les requêtes HTTP effectuées avec NSURLSession sont mises en cache dans un fichier sur l'appareil. Toute personne pouvant accéder à ce fichier (en ayant un accès physique au téléphone par exemple) pourra alors observer les requêtes et les réponses associées effectuées par l'application. Il est important de ne pas stocker en cache des informations sensibles qui pourraient être contenues dans les réponses /17

10 ANDROID- PROVIDER-PERM Restreindre les permissions sur les Content Providers au strict nécessaire Les content providers offrent des mécanismes de partages des données stockées entre les applications de l équipement. Si l application ne met pas de données à disposition des autres applications, l attribut suivant doit être positionné dans le manifest de l application : android:exported=false Si l application doit mettre à disposition des données, il faut restreindre les permissions d accès au content provider au strict nécessaire (paramétrage dans le manifest). Si seule une liste limitée d applications doit accéder au content provider (par exemple, d autres applications du même développeur), il est préférable d utiliser le mécanisme de protection par signature (les applications vont utiliser la même clef). À noter que ce mécanisme permet une bonne sécurisation d accès, tout en évitant d ajouter des permissions qui nécessiteront la confirmation de l utilisateur. Android Security Tips Using content providers 15 Android Security Tips Using Interprocess Communication 16 COMMON-PARAM-QUERY Utiliser les méthodes paramétrées pour interroger un content provider Lors de l utilisation de requêtes (SQL par exemple), il est important d utiliser les mécanismes de requêtes paramétrées permettant de s assurer de la sécurisation des variables contre les risques d injection SQL. Cette exigence est aussi valable pour les content providers sur Android. Lors de l accès à un content provider, il est nécessaire d utiliser les méthodes paramétrées fournies par Android telles que query(), update(), insert(), delete(). Le fait d utiliser ces fonctions permet de limiter les possibilités d attaques de type sql injection. Android Security Tips Using content providers BACKEND ET UTILISATION DU RESEAU Les transactions sur le réseau, tel que l accès à un serveur de backend distribuant les données à afficher, est toujours un point sensible de l application en termes de sécurité. Les points suivants sont entre autres à prendre en compte dans la sécurisation de l application (y compris le backend) : /17

11 + Les données transitant entre le backend et l équipement peuvent être sensibles (par exemple, des données métiers, ou des données personnelles de l utilisateur) ; + Une authentification des utilisateurs et des autorisations d accès au backend doivent être gérées (par le backend) ; + Les équipements mobiles se connectent souvent sur des réseaux non sûrs (par exemple, des hotspots WiFi publics). COMMON-AUTH Authentification et autorisation doivent être décidées du côté d un backend Il est important de garder en tête qu'un attaquant aura accès à l'application et à son équipement. Avec les outils appropriés, il est possible de modifier le comportement de l'application. Des décisions importantes, comme l'authentification et la gestion des autorisations ne doivent pas être prises sur l équipement, mais uniquement du côté du backend. Entre autres, les identifiants (login et mot de passe) des utilisateurs ne doivent pas être stockés sur l équipement mobile. Android Security Tips Handling Credentials 18 COMMON-TLS Chiffrer les échanges sur le réseau Dans la plupart des cas, il est nécessaire de chiffrer les flux entre l équipement et le backend par l utilisation de SSL/TLS. Les équipements mobiles peuvent se connecter sur des réseaux non sûrs, tels que des hotspots WiFi publics, et il est donc préférable de chiffrer les communications. Cette exigence s applique particulièrement à la communication faite entre l application et son backend (un webservice par exemple). Cette exigence peut éventuellement ne pas être appliquée dans le cadre d informations publiques pour lesquelles la confidentialité n est absolument pas nécessaire. Toutefois, dès lors qu un mécanisme d authentification ou d autorisation existe dans l application, il est fortement recommandé de chiffrer l ensemble des échanges (authentification, identifiant authentifié (cookie de session, token, ), données accessibles après authentification uniquement, ). Android Security Tips Using IP Networking 19 Making HTTPS requests Overview/WorkingWithHTTPAndHTTPSRequests/WorkingWithHTTPAndHTTPSRequests.html 11/17

12 ANDROID-IPC-NETWORK Ne pas utiliser le réseau pour des échanges entre applications sur le même équipement Certains développeurs peuvent mettre à disposition des informations directement en mettant un port en écoute sur le téléphone (sur localhost par exemple). Ce mécanisme ne permet pas de gérer l authentification et les permissions nativement et permet donc l accès aux données sans aucun contrôle. Par ailleurs, cette manière de faire sera plus grave si le port mis en écoute l est sur toutes les inferfaces (INADDR_ANY), puisque qu il sera potentiellement possible d accéder aux informations à distance (y compris de manière malveillante). C est pourquoi il est nécessaire de préférer les mécanismes IPC fournis nativement par Android, tels que les classes Service, Messenger, Intent, Binder, BroadcastReceiver. Ces classes permettent de vérifier l identité des applications qui se connectent à l IPC et permettent de gérer des politiques de sécurité. Android Security Tips Using IP Networking 21 Android Security Tips Using Interprocess Communication 22 COMMON-CRT Utiliser un certificat de chiffrement valide et vérifier sa validité Lors de chiffrement de flux au moyen d un certificat (par exemple, pour du HTTPS), il est primordial d utiliser un certificat valide. Un certificat peut être considéré comme valide s il répond à minima aux exigences ci-après. Par ailleurs, ces exigences doivent être vérifiées par l application à la connexion : + La date de fin de validité du certificat n est pas atteinte ; + Le certificat n est pas auto-signé ; + Les autorités de certification (y compris intermédiaires) sont reconnues par le système Android ; + Le subject (ou subject alternative) correspond bien au nom de domaine du backend accédé. Il est à noter que la vérification de ces exigences sont effectuées par les classes natives du système Android (telle que HttpURLConnection) ou ios (telle que NSURLSession). Dans le cas de l utilisation de telles classes, les mécanismes de vérification du certificat ne doivent en aucun cas être désactivés. Dans le cas de l utilisation de fonctionnalités qui n implémentent pas ces vérifications de certificat, il est nécessaire de les implémenter. Il faut également porter une attention particulière à l utilisation de librairies tierce-parties. Elles peuvent simplifier le travail du développeur, parfois au détriment de la sécurité. Un exemple pour ios est la librairie AFNetworking très utilisée, mais qui ne vérifie pas la validité des certificats /17

13 Android Security with HTTPS and SSL 23 ios Using Networking securely 24 COMMON-INPUT-VALIDATION Valider toutes les entrées sur l application (backend ou application mobile) Never Trust User Input. Toutes les entrées (données reçues, paramètres des requêtes, ajouts de fichiers, ) doivent être correctement validées afin de ne pas autoriser des actions inattendues (y compris malveillantes) : + paramètres des requêtes ; + fichiers reçus ; + données lues à partir de fichiers stockés sur l équipement ou la carte SD ; + données reçues sur le réseau (backend, webservice, ) ; + données reçues depuis un IPC (content provider, ). Il existe de nombreuses bonnes pratiques suivant les vulnérabilités liées aux erreurs de validation : + vérification de la longueur de la donnée (vulnérabilité de type buffer overflows) ; + utilisation de listes blanches dès que possible ; + utilisation de typages forts et vérifications que les données sont conformes au format (exemple : un ID qui doit être un entier strictement positif et inférieur à une valeur maximale et utilisations de regex fermées) ; + dans le cas de requêtes SQL, utilisation de requêtes paramétrées (voir COMMON- PARAM-QUERY) Android Security Tips Performing Input Validation 25 Android Security Tips Using IP Networking 26 ANDROID-SMS Ne pas utiliser les SMS pour envoyer des messages à l application Il est fortement déconseillé d utiliser le protocole SMS pour envoyer des messages à l application. Les SMS sont prévus pour être des messages user-to-user et apportent certaines limitations : Overview/SecureNetworking/SecureNetworking.html /17

14 + Les SMS ne sont ni chiffrés, ni authentifiés sur le réseau ou sur l équipement (un utilisateur pourrait envoyer de lui-même des SMS malveillants à l application) ; + Les SMS sont sujets au spoof et/ou à l interception sur le réseau ; + Les SMS sont envoyés en broadcast et peuvent être lus par toutes les applications qui possèdent la permission READ_SMS. Par ailleurs, comme énoncé dans COMMON-STORAGE, il n est pas recommandé de donner des permissions sensibles à une application (sauf si absolument nécessaire, car fonctionnalité primaire de l application). 1.4 ANTI-PIRATAGE ET BONNES PRATIQUES DE DEVELOPPEMENT ANDROID-WEBVIEW Sécuriser l utilisation des WebView Les WebView sont des classes qui permettent d inclure directement du contenu web (HTML et Javascript) dans l application et peuvent donc inclure directement des vulnérabilités web telles que les failles XSS (Cross-Site Scripting). Utilisation de Javascript Si l application n utilise pas Javascript pour la WebView, il est important de ne pas appeler la fonction setjavascriptenabled(). Cette méthode est souvent donnée dans les exemples de codes et se retrouve dans des applications en production alors que le Javascript n est pas nécessaire. Le fait de ne pas autoriser le Javascript réduit fortement la probabilité de l exploitation d une vulnérabilité. Interface Javascript L invocation de la méthode addjavascriptinterface() est à utiliser avec précaution, car elle autorise l appel de codes Javascript qui aura accès aux opérations normalement réservées aux applications Android. Dans ce cas, les entrées doivent être validées afin d éviter toute injection de code Javascript non autorisé. Données sensibles et cache Dans le cas classique de l utilisation de WebView, les pages web affichées peuvent être mises en cache par le système Android. S il s agit de données sensibles, il ne faut pas garder ce cache pour éviter une compromission des données contenues dans ce dernier. Pour cela, deux moyens : + Côté serveur, envoyer l entête HTTP Cache-Control : no-cache + Côté application, appeler la méthode clearcache() 14/17

15 Android Security Tips Using WebView 27 COMMON-FILES Ne pas laisser de fichiers inutiles dans le répertoire de l'application Il est nécessaire de restreindre au minimum les fichiers distribués avec l'application. Seuls les fichiers strictement utiles au bon fonctionnement de l application doivent être distribués avec l ensemble des fichiers contenus dans l application. En particulier, il n'est pas autorisé de laisser des documentations (par exemple, pdf) sur les librairies utilisées, des fichiers de debug, COMMON-UDID Ne pas utiliser les identifiants uniques de l équipement Ne pas utiliser d'identifiant unique (MAC, UDID, IMEI, IP) à l équipement pour des opérations par l application qui ne le nécessitent pas. Par exemple, si l application nécessite un identifiant unique (GUID), il est préférable de générer un grand nombre unique et de le stocker, plutôt que d utiliser le numéro IMEI du téléphone. Sur ios, il est aussi possible d utiliser la fonction de génération d un UUID par «vendor» (développeur) : ml#//apple_ref/occ/instp/uidevice/identifierforvendor Cette exigence permet de ne pas exposer inutilement des données personnelles ou sensibles de l utilisateur sans nécessité. Par ailleurs, les données personnelles sont soumises à des contraintes de sécurité plus fortes (IMEI par exemple), alors qu un numéro généré aléatoirement pourra être utilisé plus simplement et suffira généralement aux besoins de l application. Android Security Tips Handling User Data 28 Android Developers Blog Identifying App Installations 29 OWASP Mobile Application Coding Guidelines Authentication and Password Management F 30 COMMON-CRYPTO Utiliser des moyens cryptographiques robustes Si l application nécessite des moyens cryptographiques, il est primordial d utiliser des algorithmes existants, sûrs et robustes, et en aucun cas de redévelopper ses propres algorithmes de cryptographie (ch. Using Telephony Network) /17

16 Voici quelques exemples de bonnes pratiques concernant les moyens cryptographiques : + communication sécurisée sur le réseau avec TLS avec HttpsURLConnection ou SSLSocket pour Android, ou NSURLSession pour ios. + génération de nombres aléatoires avec SecureRandom pour Android, ou SecRandomCopyBytes pour ios. + génération des clefs de cryptographie avec SecureRandom et KeyGenerator pour Android et CommonCrypto pour ios. + stockage de données sensibles (ex : clefs de cryptographie) sur l équipement dans le KeyStore pour Android ou le Keychain pour ios. + utilisation d algorithmes approuvés par le NIST, tels que AES ou SHA2 Android Security Tips Using Cryptography 31 OWASP Mobile Application Coding Guidelines Authentication and Password Management 32 IOS-APP-SCHEME Filtrer les entrées par une URL scheme Une application ios permet d'ajouter des URL schemes sur le téléphone. Par exemple, une URL du type myapp://train/list pourra être envoyée directement à l'application. Il est nécessaire que l'accès à ces URL et les données présentes dans l'url soient vérifiés afin de ne pas produire de comportement inattendu ou non autorisé. Using URL Schemes to Communicate with Apps 33 IOS-APP-ENCRYPT Chiffrer l'application pour sa distribution dans un store Pour distribuer l'application, cette dernière doit être chiffrée (encrypted). C'est le cas par défaut, dans l'apple Store /Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP CH6-SW1 16/17