Fonctionnalités de test et de débogage

Catégorie OWASP : MASVS-CODE : qualité du code

Présentation

La publication de builds de production incluant des fonctionnalités de test ou de débogage peut avoir un impact négatif sur la stratégie de sécurité de l'application. Ces fonctionnalités permettent aux développeurs de découvrir et d'identifier les bugs dans les cas d'utilisation prévus avant ou après la publication d'une nouvelle version. Elles ne doivent pas être accessibles au public.

Voici quelques exemples de fonctionnalités de test/débogage :

Menus masqués
Options pour activer des journaux de débogage
Options pour modifier le flux de l'application
Options pour contourner les processus de paiement ou d'abonnement
Options pour contourner l'authentification
Tests des activités spécifiques à l'application

Tout ce qui précède peut être exploité par un utilisateur malveillant afin de modifier le flux prévu de l'application ou de récupérer des informations système afin de personnaliser d'autres attaques.

Le risque en laissant les fonctionnalités de test ou de débogage exposées peut varier en fonction de l'action associée aux fonctionnalités de débogage elles-mêmes.

Un autre risque pour l'application est l'attribut android:debuggable défini dans l'élément <application> d'AndroidManifest.xml. Comme indiqué dans l'article android:debuggable, le déploiement d'une application de production avec l'ensemble de valeurs mentionné ci-dessus permet aux utilisateurs malveillants d'accéder aux ressources administratives, normalement inaccessibles.

Impact

Un utilisateur malveillant interagissant avec une fonctionnalité de test ou de débogage dans un build de production peut entraîner des résultats inattendus. L'impact d'une action est directement lié aux autorisations attribuées à la fonctionnalité. Plus le nombre d'autorisations est élevé, plus l'impact d'une exploitation active est important. Ces fonctionnalités d'une application peuvent être utilisées pour contourner un certain nombre de protections, contourner des paywalls, récupérer des informations sur le système ou l'utilisateur, ou pour déclencher des activités de test.

Stratégies d'atténuation

Éviter d'utiliser des composants de débogage

Les fonctionnalités de test ou de débogage ne doivent jamais être implémentées dans les composants d'application de production, tels que les activités, les broadcast receivers, les fournisseurs de services ou de contenu. En effet, une fois exportées, elles peuvent être exécutées par tout autre processus sur l'appareil. Définir le composant de débogage comme non exporté (android:exported="false" ) ne constitue pas une protection valide pour les fonctionnalités, car n'importe quel appareil en mode root peut toujours l'exécuter via l'outil Android Debug Bridge (ADB) si l'option de débogage est activée.

Limiter les fonctionnalités de débogage ou de test à la préproduction des builds

L'exécution de toute fonction de test ou de débogage dans les applications ne doit être limitée qu'à un ensemble restreint de builds de préproduction, afin de permettre uniquement aux développeurs de déboguer ou de tester les fonctionnalités de l'application dans un environnement contrôlé. Pour ce faire, créez une version de l'application dédiée au test ou au débogage et des tests d'instrumentation avancés pour celle-ci. Cela vous permet de vous assurer que toutes les fonctionnalités de test ou de débogage sont exécutées sur une version isolée.

Implémenter des tests d'interface utilisateur automatisés

Lorsque vous exécutez des tests sur une application, optez pour des tests d'interface utilisateur automatisés, car ils sont reproductibles, peuvent être exécutés dans un environnement séparé et ne sont pas sujets aux erreurs humaines.