Sécuriser les communications sur Android

Avec toutes les violations de données récentes, la confidentialité est devenue un sujet important. Presque toutes les applications communiquent sur le réseau, il est donc important de prendre en compte la sécurité des informations utilisateur. Dans cet article, vous découvrirez les meilleures pratiques actuelles pour sécuriser les communications de votre application Android.

Utilisez HTTPS

Lorsque vous développez votre application, il est recommandé de limiter vos demandes réseau à celles qui sont essentielles. Pour les éléments essentiels, assurez-vous qu’ils sont créés via HTTPS au lieu de HTTP. HTTPS est un protocole qui crypte le trafic afin qu’il ne puisse pas être facilement intercepté par des écoutes indiscrètes. L’avantage d’Android est que la migration est aussi simple que de changer l’URL de http à https.

En fait, Android N et les versions supérieures peuvent appliquer HTTPS en utilisant Configuration de la sécurité réseau d’Android.

Dans Android Studio, sélectionnez le app / res / xml répertoire de votre projet. Créer le xml répertoire s’il n’existe pas déjà. Sélectionnez-le et cliquez sur Fichier> Nouveau fichier. Appeler network_security_config.xml. Le format du fichier est le suivant:

Pour indiquer à Android d’utiliser ce fichier, ajoutez le nom du fichier à la balise d’application dans le AndroidManifest.xml fichier:

Mettre à jour les fournisseurs de crypto

Le protocole HTTPS a été exploité plusieurs fois au fil des ans. Lorsque les chercheurs en sécurité signalent des vulnérabilités, les défauts sont souvent corrigés. L’application des correctifs garantit que les connexions réseau de votre application utilisent les protocoles standard de l’industrie les plus récents. Les versions les plus récentes des protocoles contiennent moins de faiblesses que les précédentes.

Pour mettre à jour le fournisseurs de crypto, vous devrez inclure les services Google Play. Dans votre fichier module de build.gradle, ajoutez la ligne suivante à la section dépendances:

le Filet de sécurité services API a beaucoup plus de fonctionnalités, y compris la Navigation sûre API qui vérifie les URL pour voir si elles ont été marquées comme une menace connue, et un reCAPTCHA API pour protéger votre application contre les spammeurs et autres trafics malveillants.

Après avoir synchronisé Gradle, vous pouvez appeler le ProviderInstallerde installIfNeededAsync méthode:

le onProviderInstalled() est appelée lorsque le fournisseur est mis à jour avec succès ou est déjà à jour. Autrement, onProviderInstallFailed(int errorCode, Intent recoveryIntent) est appelé.

Certificat et épinglage de clé publique

Lorsque vous établissez une connexion HTTPS à un serveur, un certificat numérique est présenté par le serveur et validé par Android pour s’assurer que la connexion est sécurisée. Le certificat peut être signé avec un certificat d’une autorité de certification intermédiaire. Ce certificat utilisé par l’autorité intermédiaire peut à son tour être signé par une autre autorité intermédiaire, etc., ce qui est digne de confiance tant que le dernier certificat est signé par une autorité de certification racine déjà approuvée par Android OS.

Si l’un des certificats de la chaîne de confiance n’est pas valide, la connexion n’est pas sécurisée. Bien que ce soit un bon système, il n’est pas infaillible. Il est possible qu’un attaquant demande à Android OS d’accepter des certificats personnalisés. Les mandataires d’interception peuvent posséder un certificat de confiance, et si l’appareil est contrôlé par une entreprise, l’entreprise peut avoir configuré l’appareil pour accepter son propre certificat. Ces scénarios permettent une attaque «homme au milieu», permettant au trafic HTTPS d’être déchiffré et lu.

L’épinglage de certificat vient à la rescousse en vérifiant le certificat du serveur présenté par rapport à une copie du certificat attendu. Cela empêche l’établissement de connexions lorsque le certificat est différent de celui attendu.

Afin d’implémenter l’épinglage sur Android N et supérieur, vous devez ajouter un hachage (appelé pins) du certificat dans le network_security_config.xml fichier. Voici un exemple d’implémentation:

Pour trouver les broches d’un site spécifique, vous pouvez aller à Laboratoires SSL, entrez sur le site et cliquez sur Soumettre. Ou, si vous développez une application pour une entreprise, vous pouvez la demander à l’entreprise.

En relation :  Google ajoute la traduction vocale en temps réel à Gboard

Remarque: si vous devez prendre en charge des appareils exécutant une version du système d’exploitation antérieure à Android N, vous pouvez utiliser le TrustKit bibliothèque. Il utilise le fichier de configuration de la sécurité réseau exactement de la même manière.

Désinfection et validation

Avec toutes les protections jusqu’à présent, vos connexions devraient être assez sécurisées. Même ainsi, n’oubliez pas la validation de programmation régulière. Faire confiance aveuglément aux données reçues du réseau n’est pas sûr. Une bonne pratique de programmation est la «conception par contrat», où les entrées et les sorties de vos méthodes satisfont un contrat qui définit des attentes d’interface spécifiques.

Par exemple, si votre serveur attend une chaîne de 48 caractères ou moins, assurez-vous que l’interface ne renverra que 48 caractères au maximum.

Si vous n’attendez que des chiffres du serveur, vos entrées doivent vérifier cela. Bien que cela aide à éviter des erreurs innocentes, cela réduit également la probabilité d’attaques par injection et par corruption de la mémoire. Cela est particulièrement vrai lorsque ces données sont transmises à NDK ou JNI—Code C et C ++ natif.

Il en va de même pour l’envoi de données au serveur. N’envoyez pas aveuglément des données, surtout si elles sont générées par l’utilisateur. Par exemple, il est recommandé de limiter la longueur de la saisie utilisateur, surtout si elle sera exécutée par un serveur SQL ou toute technologie qui exécutera du code.

Bien que la sécurisation d’un serveur contre les attaques dépasse le cadre de cet article, en tant que développeur mobile, vous pouvez faire votre part en supprimant les caractères de la langue utilisée par le serveur. De cette façon, l’entrée n’est pas sensible aux attaques par injection. Certains exemples sont des guillemets, des points-virgules et des barres obliques supprimés lorsqu’ils ne sont pas essentiels pour la saisie utilisateur:

Si vous connaissez exactement le format attendu, vous devriez le vérifier. Un bon exemple est la validation des e-mails:

Les fichiers peuvent également être vérifiés. Si vous envoyez une photo à votre serveur, vous pouvez vérifier qu’il s’agit d’une photo valide. Les deux premiers octets et les deux derniers octets sont toujours FF D8 et FF D9 pour le format JPEG.

Soyez prudent lorsque vous affichez une alerte d’erreur qui affiche directement un message du serveur. Les messages d’erreur peuvent divulguer des informations de débogage privées ou liées à la sécurité. La solution consiste à demander au serveur d’envoyer un code d’erreur que le client recherche pour afficher un message prédéfini.

Communication avec d’autres applications

Pendant que vous protégez la communication vers et depuis l’appareil, il est également important de protéger IPC. Il y a eu des cas où les développeurs ont laissé des fichiers partagés ou ont implémenté des sockets pour échanger des informations sensibles. Ce n’est pas sûr. Il vaut mieux utiliser Intentions. Vous pouvez envoyer des données à l’aide d’un Intention en fournissant le nom du package comme ceci:

Pour diffuser des données vers plusieurs applications, vous devez vous assurer que seules les applications signées avec votre clé de signature obtiendront les données. Sinon, les informations que vous envoyez peuvent être lues par n’importe quelle application qui s’inscrit pour recevoir la diffusion. De même, une application malveillante peut envoyer une diffusion à votre application si vous vous êtes inscrit pour recevoir la diffusion. Vous pouvez utiliser une autorisation lors de l’envoi et de la réception d’émissions où Signature est utilisé comme Niveau de protection. Vous pouvez définir une autorisation personnalisée dans le fichier manifeste comme ceci:

Ensuite, vous pouvez accorder l’autorisation comme ceci:

En relation :  Comment voir et supprimer les données que Windows 10 collecte et envoie à Microsoft

Les deux applications doivent disposer des autorisations dans le fichier manifeste pour que cela fonctionne. Pour envoyer l’émission:

Vous pouvez également utiliser setPackage(String) lors de l’envoi d’une diffusion pour la limiter à un ensemble d’applications correspondant au package spécifié. Réglage android:exported à false dans le fichier manifeste exclura les diffusions reçues de l’extérieur de votre application.

Chiffrement de bout en bout

Il est important de comprendre les limites du HTTPS pour protéger les communications réseau. Dans la plupart des implémentations HTTPS, le chiffrement est terminé au niveau du serveur. Par exemple, votre connexion au serveur d’une entreprise peut être via HTTPS, mais une fois que ce trafic atteint le serveur, il n’est pas chiffré. Il peut ensuite être transmis à d’autres serveurs, soit en établissant une autre session HTTPS, soit en l’envoyant en clair. La société est en mesure de voir les informations qui ont été envoyées, et dans la plupart des cas, c’est une exigence pour les opérations commerciales. Cependant, cela signifie également que l’entreprise pourrait transmettre les informations à des tiers en clair.

Il existe une tendance récente appelée «cryptage de bout en bout» où seuls les deux dispositifs de communication d’extrémité peuvent lire le trafic. Un bon exemple est une application de chat cryptée où deux appareils mobiles communiquent entre eux via un serveur; seuls l’expéditeur et le destinataire peuvent lire les messages de l’autre.

Une analogie pour vous aider à comprendre le chiffrement de bout en bout consiste à imaginer que vous voulez que quelqu’un vous envoie un message que vous seul pouvez lire. Pour ce faire, vous leur fournissez une boîte avec un cadenas ouvert dessus (la clé publique) pendant que vous gardez la clé du cadenas (clé privée). L’utilisateur écrit un message, le met dans la boîte, verrouille le cadenas et vous le renvoie. Vous seul pouvez lire le message car vous êtes le seul à avoir la clé pour déverrouiller le cadenas.

Avec le chiffrement de bout en bout, les deux utilisateurs s’envoient leurs clés. Le serveur fournit uniquement un service de communication, mais il ne peut pas lire le contenu de la communication. Bien que les détails de mise en œuvre sortent du cadre de cet article, il s’agit d’une technologie puissante. Si vous souhaitez en savoir plus sur cette approche, un bon point de départ est le Dépôt GitHub pour l’open-source Projet Signal.

Conclusion

Avec toutes les nouvelles lois sur la confidentialité telles que le RGPD, la sécurité est de plus en plus importante. C’est souvent un aspect négligé du développement d’applications mobiles.

Dans ce didacticiel, vous avez couvert les meilleures pratiques en matière de sécurité, notamment l’utilisation de HTTPS, l’épinglage de certificats, la désinfection des données et le chiffrement de bout en bout. Ces bonnes pratiques doivent servir de base à la sécurité lors du développement de votre application mobile. Si vous avez des questions, n’hésitez pas à les laisser ci-dessous, et pendant que vous êtes ici, consultez certains de mes autres tutoriels sur la sécurité des applications Android!

Moyens Staff
Moyens I/O Staff vous a motivé, donner des conseils sur la technologie, le développement personnel, le style de vie et des stratégies qui vous aider.