Tester les applications Cordova

Natif ou hybride :

Les frameworks hybrides comme Cordova permettent de développer une seule application pour plusieurs plateformes (Android, iOS, Windows Phone, FireOS, FirefoxOS...). Ce framework est simple et rapide à utiliser, et offre généralement une API unique pour toutes les plateformes.

Les applications hybrides souffrent toutefois de problèmes de performance, même si les dernières versions ont nettement amélioré la vitesse du framework et que le délai supplémentaire est imperceptible sur les téléphones modernes.

Cordova :

Cordova est une plateforme de développement d'applications mobiles hybrides en HTML5, CSS3 et JavaScript. Elle est open source et distribuée sous licence Apache version 2.0 ; ses composants de base offrent un riche ensemble de fonctionnalités en JavaScript, qui peut être étendu à l'aide de langages natifs.

Fonctionnement interne :

Pour examiner la sécurité d'une application mobile Cordova, il est important de comprendre au préalable le fonctionnement interne du framework afin de savoir quoi chercher et où.

config.xml :

config.xml est le principal fichier de configuration qui définit plusieurs aspects de l'application mobile, comme les plugins activés, les paramètres propres à chaque plateforme et la liste des hooks personnalisés. Pour plus d'informations sur les options du fichier config.xml, consultez l'URL suivante.

Pour un audit de sécurité, c'est la première chose à vérifier pour se faire une idée initiale des capacités de l'application.

<?xml version='1.0' encoding='utf-8'?>
<widget id="io.cordova.hellocordova" version="0.0.1" xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0">
  <name>HelloCordova</name>
  <description>
      A sample Apache Cordova application that responds to the deviceready event.
  </description>
  <author email="dev@cordova.apache.org" href="http://cordova.io">
      Apache Cordova Team
  </author>
  <content src="index.html" />
  <plugin name="cordova-plugin-whitelist" spec="1" />
  <access origin="*" />
  <allow-intent href="http://*/*" />
  <allow-intent href="https://*/*" />
  <allow-intent href="tel:*" />
  <allow-intent href="sms:*" />
  <allow-intent href="mailto:*" />
  <allow-intent href="geo:*" />
  <platform name="android">
      <allow-intent href="market:*" />
  </platform>
  <platform name="ios">
      <allow-intent href="itms:*" />
      <allow-intent href="itms-apps:*" />
  </platform>
</widget>

Le fichier config.xml se trouve à la racine du dossier du projet Cordova, dont la structure est la suivante :

• hooks : permet de modifier le fonctionnement de la CLI Cordova
• platforms : contient le code natif de chaque plateforme. Les développeurs peuvent le modifier pour étendre ou altérer le framework Cordova, bien que la méthode recommandée soit d'ajouter des plugins.
• plugins : les plugins étendent l'API JavaScript et sont stockés dans ce dossier
• www : c'est le dossier principal qui contient le code HTML, JavaScript et CSS.

Whitelist :

Le plugin whitelist est un plugin de sécurité important qui définit les URI autorisés pour la navigation, les intents et l'accès réseau. Ce plugin permet aussi de définir une CSP (content-security-policy), une protection essentielle contre les vulnérabilités de cross-site scripting (XSS), extrêmement dangereuses pour les applications Cordova.

Pour plus d'informations sur la CSP, je recommande vivement ce lien ainsi que cette présentation sur la nouvelle protection fondée sur les nonces.

<!-- Good default declaration:
    * gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication
    * https://ssl.gstatic.com is required only on Android and is needed for TalkBack to function properly
    * Disables use of eval() and inline scripts in order to mitigate risk of XSS vulnerabilities. To change this:
        * Enable inline JS: add 'unsafe-inline' to default-src
        * Enable eval(): add 'unsafe-eval' to default-src
-->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com; style-src 'self' 'unsafe-inline'; media-src *">

<!-- Allow everything but only from the same origin and foo.com -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' foo.com">

<!-- This policy allows everything (eg CSS, AJAX, object, frame, media, etc) except that 
    * CSS only from the same origin and inline styles,
    * scripts only from the same origin and inline styles, and eval()
-->
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">

<!-- Allows XHRs only over HTTPS on the same domain. -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' https:">

<!-- Allow iframe to https://cordova.apache.org/ -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; frame-src 'self' https://cordova.apache.org">

Plugins :

Les plugins définissent l'ensemble des fonctionnalités prises en charge par l'application. Cordova dispose d'une riche liste de plugins existants qui donnent accès à des fonctionnalités courantes comme l'appareil photo, le GPS, le réseau et la batterie. Les développeurs peuvent créer leurs propres plugins ou intégrer l'un des centaines de plugins open source disponibles ici.

Les plugins Cordova sont faciles à développer : sur Android par exemple, il suffit d'étendre la classe CordovaPlugin et de surcharger l'une des méthodes execute.

Frameworks complémentaires

Les applications développées avec Cordova utilisent généralement des frameworks complémentaires comme Sencha ou Angular, ou des versions étendues de Cordova comme PhonGap et Ionic. Ces frameworks étendent les fonctionnalités de Cordova pour simplifier considérablement le développement d'applications ; Ionic fournit par exemple des services tels que les notifications push, les tests A/B, l'analytique, le déploiement de code et les builds automatisés.

Ces frameworks ont leur propre logique et leurs propres fichiers de configuration.

Débogage :

Déboguer le code, que ce soit pour le développement ou pour les tests de sécurité, est très utile pour identifier des bugs et des vulnérabilités ou pour faciliter la compréhension de l'application. Les outils de débogage disponibles dépendent de la plateforme cible. Sur Android, il est possible d'utiliser le débogage à distance de Chrome, qui donne accès à tous les outils de développement à l'intérieur de Cordova. Sur iOS, il est possible d'utiliser le Safari Web Inspector, qui offre un ensemble de fonctionnalités très similaire.

Cordova est devenu une véritable alternative pour créer des applications mobiles. Du point de vue de la sécurité, Cordova introduit de nouveaux défis et étend la surface d'attaque ; voici quelques faiblesses de sécurité courantes et points d'attention :

Faiblesses de sécurité courantes :

Whitelist non sécurisée :

Le plugin whitelist de Cordova est une pierre angulaire de la sécurité des applications Cordova. Comme indiqué plus haut, ce plugin permet de définir les URI autorisés vers lesquels la WebView peut naviguer, les intents autorisés que l'application peut demander dans le cas d'Android, ainsi que les accès réseau autorisés.

Une autre fonctionnalité importante du plugin est la prise en charge des politiques CSP pour se protéger contre les vulnérabilités XSS. La CSP est nécessaire car les filtres de la whitelist ne s'appliquent pas aux Websockets ni à la balise HTML5 <video>.

Des politiques permissives comme :

<!-- Don't block any requests -->
<access origin="*" />

sont non sécurisées, malheureusement courantes, et facilitent l'exploitation des vulnérabilités XSS dans l'application. Cette vulnérabilité est vérifiée par notre scanner de sécurité accessible librement.

Cross Site Scripting (XSS) :

Selon la définition de l'OWASP, les attaques de Cross-Site Scripting (XSS) sont un type d'injection dans lequel des scripts malveillants sont injectés dans des sites web par ailleurs bénins et de confiance. Les attaques XSS se produisent lorsqu'un attaquant utilise une application web pour envoyer du code malveillant, généralement sous la forme d'un script côté navigateur, à un autre utilisateur final. Les failles qui permettent à ces attaques de réussir sont très répandues et apparaissent partout où une application web utilise des données saisies par un utilisateur dans la sortie qu'elle génère, sans les valider ni les encoder.

Les vulnérabilités XSS s'appliquent aux applications Cordova et sont extrêmement dangereuses, car elles équivalent à une exécution de code complète dans le contexte de l'application mobile. L'étendue des possibilités dépend de la liste des plugins chargés.

Plugins inutilisés

Réduire la surface d'attaque de l'application est important pour limiter l'impact de vulnérabilités comme les XSS, en particulier pour les plugins aux fonctionnalités dangereuses, comme l'accès aux fichiers, à l'appareil photo et aux contacts.

Les plugins peuvent aussi souffrir de leurs propres classes de vulnérabilités, comme l'injection SQL, l'accès non sécurisé au système de fichiers ou l'injection XXE.

Versions de Cordova non corrigées :

Cordova a souffert par le passé de plusieurs vulnérabilités contournant les restrictions de la whitelist, permettant de charger des ressources arbitraires. Corriger la vulnérabilité exige généralement de compiler et de publier une nouvelle version de l'application.

Pour une liste des vulnérabilités connues, consultez l'URL suivante

Android reste Android et iOS reste iOS : outre les nouvelles classes de vulnérabilités introduites par Cordova, en particulier les XSS, une application mobile Cordova reste une application mobile, et les vulnérabilités classiques des applications mobiles s'appliquent toujours.