Communications en texte clair

Catégorie OWASP : MASVS-NETWORK : communication réseau

Présentation

Autoriser les communications réseau en texte clair dans une application Android signifie que toute personne surveillant le trafic réseau peut voir et manipuler les données transmises. Il s'agit d'une faille si les données transmises incluent des informations sensibles telles que des mots de passe, des numéros de carte de crédit ou d'autres informations personnelles.

Que vous envoyiez des informations sensibles ou non, l'utilisation du texte clair peut toujours constituer une faille, car le trafic en texte clair peut également être manipulé par le biais d'attaques réseau telles que l'ARP ou l'empoisonnement DNS, ce qui peut permettre aux pirates informatiques d'influencer le comportement d'une application.

Impact

Lorsqu'une application Android envoie ou reçoit des données en texte clair sur un réseau, toute personne qui surveille le réseau peut intercepter et lire ces données. Si ces données incluent des informations sensibles telles que des mots de passe, des numéros de carte de crédit ou des messages personnels, cela peut entraîner un vol d'identité, une fraude financière et d'autres problèmes graves.

Par exemple, une application transmettant des mots de passe en texte clair peut exposer ces identifiants à un acteur malveillant interceptant le trafic. Ces données peuvent ensuite être utilisées pour obtenir un accès non autorisé aux comptes de l'utilisateur.

Risque: canaux de communication non chiffrés

La transmission de données via des canaux de communication non chiffrés expose les données partagées entre l'appareil et les points de terminaison de l'application. Ces données peuvent être interceptées et potentiellement modifiées par un pirate informatique.

Stratégies d'atténuation

Les données doivent être envoyées via des canaux de communication chiffrés. Les protocoles sécurisés doivent être utilisés à la place des protocoles qui n'offrent pas de fonctionnalités de chiffrement.

Risques spécifiques

Cette section présente les risques qui nécessitent des stratégies d'atténuation non standards ou qui ont été atténués à certains niveaux du SDK et qui sont ici complets.

Risque: HTTP

Les conseils de cette section ne s'appliquent qu'aux applications qui ciblent Android 8.1 (niveau d'API 27) ou version antérieure. À partir d'Android 9 (niveau d'API 28), les clients HTTP tels que URLConnection, Cronet et OkHttp appliquent l'utilisation de HTTPS. Par conséquent, la prise en charge du texte clair est désactivée par défaut. Toutefois, sachez que d'autres bibliothèques clientes HTTP telles que Ktor ne sont pas susceptibles d'appliquer ces restrictions sur le texte clair et doivent être utilisées avec précaution.

Stratégies d'atténuation

Utilisez la fonctionnalité NetworkSecurityConfig.xml pour désactiver le trafic en texte clair et appliquer HTTPS à votre application, avec des exceptions uniquement pour les domaines spécifiques requis (généralement à des fins de débogage):

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Cette option permet d'éviter les régressions accidentelles dans les applications en raison de modifications des URL fournies par des sources externes telles que des serveurs backend.

Risque: FTP

L'utilisation du protocole FTP pour échanger des fichiers entre des appareils présente plusieurs risques, le plus important étant l'absence de chiffrement sur le canal de communication. Des alternatives plus sûres telles que SFTP ou HTTPS doivent être utilisées à la place.

Stratégies d'atténuation

Lorsque vous implémentez des mécanismes d'échange de données sur Internet dans votre application, vous devez utiliser un protocole sécurisé tel que HTTPS. Android met à disposition un ensemble d'API qui permet aux développeurs de créer une logique client-serveur. Cela peut être sécurisé à l'aide du protocole TLS (Transport Layer Security), qui garantit que l'échange de données entre deux points de terminaison est chiffré, empêchant ainsi les utilisateurs malveillants d'écouter les communications et de récupérer des données sensibles.

En règle générale, les architectures client-serveur s'appuient sur des API appartenant aux développeurs. Si votre application dépend d'un ensemble de points de terminaison d'API, assurez-vous d'une sécurité en profondeur en suivant ces bonnes pratiques de sécurité pour protéger les communications HTTPS:

  • Authentification : les utilisateurs doivent s'authentifier à l'aide de mécanismes sécurisés tels que OAuth 2.0. L'authentification de base est généralement déconseillée, car elle ne fournit pas de mécanismes de gestion des sessions et, si les identifiants sont stockés de manière incorrecte, elle peut être décodée à partir de Base64.
  • Autorisation : les utilisateurs ne doivent avoir accès qu'aux ressources prévues, conformément au principe du moindre privilège. Pour ce faire, adoptez des solutions de contrôle des accès rigoureuses pour les composants de l'application.
  • Assurez-vous que les suites de chiffrement les plus récentes et les plus réfléchies sont utilisées, en suivant les bonnes pratiques de sécurité. Par exemple, envisagez de prendre en charge le protocole TLSv1.3 avec rétrocompatibilité, si nécessaire, pour les communications HTTPS.

Risque: protocoles de communication personnalisés

L'implémentation de protocoles de communication personnalisés ou d'essayer d'implémenter manuellement des protocoles bien connus peut être dangereux.

Bien que les protocoles personnalisés permettent aux développeurs de créer une solution unique qui s'adapte aux besoins prévus, toute erreur lors du processus de développement peut entraîner des failles de sécurité. Par exemple, des erreurs lors du développement de mécanismes de gestion des sessions peuvent permettre aux pirates informatiques d'intercepter les communications et de récupérer des informations sensibles à la volée.

En revanche, l'implémentation de protocoles bien connus tels que HTTPS sans utiliser d'OS ni de bibliothèques tierces bien entretenues augmente la probabilité d'introduire des erreurs de codage qui peuvent rendre difficile, voire impossible, la mise à jour du protocole que vous avez implémenté si nécessaire. De plus, cela peut entraîner le même type de failles de sécurité que l'utilisation de protocoles personnalisés.

Stratégies d'atténuation

Utiliser des bibliothèques gérées pour implémenter des protocoles de communication bien connus

Pour implémenter des protocoles bien connus tels que HTTPS dans votre application, vous devez utiliser des bibliothèques d'OS ou des bibliothèques tierces gérées.

Les développeurs peuvent ainsi choisir des solutions qui ont été testées minutieusement, améliorées au fil du temps et qui reçoivent en permanence des mises à jour de sécurité pour corriger les failles courantes.

De plus, en optant pour des protocoles bien connus, les développeurs bénéficient d'une large compatibilité entre différents systèmes, plates-formes et IDE, ce qui réduit le risque d'erreurs humaines lors du processus de développement.

Utiliser SFTP

Ce protocole chiffre les données en transit. Des mesures supplémentaires doivent être prises en compte lors de l'utilisation de ce type de protocole d'échange de fichiers:

  • SFTP est compatible avec différents types d'authentification. Au lieu de l'authentification par mot de passe, la méthode d'authentification par clé publique doit être utilisée. Ces clés doivent être créées et stockées de manière sécurisée. Pour ce faire, nous vous recommandons d'utiliser Android Keystore.
  • Assurez-vous que les algorithmes de chiffrement compatibles respectent les bonnes pratiques de sécurité.

Ressources