licence : une licence à l‘Apache Software Foundation (ASF) au titre d’un ou plusieurs contrats de licence pour le cotisant. Voir le fichier avis distribué avec ce travail d‘information additionnelle concernant les droits d’auteur. L'ASF licenses ce fichier vous sous Apache License, Version 2.0 (la “licence”) ; vous ne pouvez utiliser ce fichier sauf en conformité avec la licence. Vous pouvez obtenir une copie de la licence à
http://www.Apache.org/licenses/License-2.0 sauf si requis par la loi applicable ou accord écrit, distribué sous la licence de logiciel est distribué sur un « Tel quel » fondement, sans garanties ou CONDITIONS d'aucune sorte, explicite ou implicite. Voir la licence pour la langue spécifique régissant les autorisations et les limites
Le guide suivant contient quelques meilleures pratiques de sécurité que vous devriez considérer lors du développement d‘une application de Cordova. S’il vous plaît être conscient que la sécurité est un sujet très compliqué et c‘est pourquoi ce guide n’est pas exhaustif. Si vous croyez que vous pouvez contribuer à ce guide, s‘il vous plaît n’hésitez pas à déposer une question au traqueur de bogue de Cordova sous “Documentation”. Ce guide est conçu pour être applicable au développement général de Cordova (toutes plates-formes), mais on notera des considérations particulières spécifiques à la plateforme.
Lire et comprendre le Guide liste blanche
Domaine liste blanche ne fonctionne pas sur Android API 10 et en dessous et WP8 pour iframes et XMLHttpRequest. Autrement dit, un attaquant peut charger n‘importe quel domaine dans un iframe et tout script sur cette page au sein de l’iframe peut accéder directement à Cordova JavaScript objets et les objets de Java natives correspondantes. Prenez cela en considération lors de la génération d‘applications pour ces plateformes. En pratique, cela signifie veiller à ce que vous ciblez un Android API supérieur à 10, et si possible ne pas utiliser un iframe pour charger le contenu externe - utilisent le plugin d’inAppBrowser ou d'autres plugins tiers.
Si le contenu est servi dans une iframe d‘un domaine dans la liste blanche, ce domaine auront accès au pont de Cordova native. Cela signifie que si vous liste blanche un réseau publicitaire de tierce partie et servir ces annonces via un iframe, il est possible qu’une annonce malveillant sera en mesure de sortir de l‘iframe et effectuer des actions malveillantes. Pour cette raison, vous devez généralement pas utiliser iframes à moins que vous contrôlez le serveur qui héberge le contenu de l’iframe. Notez également qu‘il existe des plugins tiers disponibles pour soutenir les réseaux de publicité. Notez que cette instruction n’est pas vraie pour iOS, qui intercepte tout, y compris les connexions de l'iframe.
Cordova ne supporte pas le vrai certificat épinglage. Le principal obstacle à cela est un manque d‘API natives dans Android d’interception des connexions SSL pour effectuer la vérification du certificat du serveur. (Même si il est possible de de certificat épinglage sur Android en Java à l‘aide de la JSSE, le mode Web sur Android est écrit en C++ et connexions au serveur sont gérées pour vous par le webview, donc il n’est pas possible d‘utiliser Java et JSSE là.) Depuis Apache Cordova est destinée à offrir une API cohérente sur plusieurs plateformes, n’ayant ne pas une capacité dans une plateforme importante casse que l'uniformité.
Il y a des façons de rapprocher l‘épinglage de certificat, par exemple, vérifier la que clé publique du serveur (empreinte digitale) est la valeur attendue lorsque votre application démarre ou à d’autres moments différents au cours de la durée de vie de votre application. Il y a des plugins tiers disponibles pour Cordova qui peut le faire. Cependant, ce n'est pas la même chose que le vrai certificat épinglage qui vérifie automatiquement la valeur attendue à chaque connexion au serveur.
Il n‘est pas recommandé d’utiliser des certificats auto-signés sur votre serveur. Si tu désires SSL, il est fortement recommandé que votre serveur possède un certificat qui a été dûment signé par une CA connue (autorité de certification). L‘incapacité de vrai certificat épinglage fait c’est important.
La raison est qu‘accepter les certificats auto-signés contourne la validation de chaîne de certificat, qui permet à n’importe quel certificat de serveur à être considéré comme valide par l‘appareil. Cela ouvre la communication aux attaques man-in-the-middle. Il devient très facile pour un pirate d’intercepter et de lire toutes les communications entre l‘appareil et le serveur non seulement, mais aussi à modifier la communication. L’appareil ne saura jamais que ce qui se passe parce qu‘il ne vérifie pas que le certificat du serveur est signé par une autorité de certification approuvée. Le dispositif n’a aucune preuve que le serveur est qui elle attend. En raison de la facilité de faire une attaque man-in-the-middle, acceptant des certificats auto-signés est seulement marginalement mieux que juste en cours d‘exécution http au lieu de https sur un réseau non approuvé. Oui, le trafic devrait être crypté, mais il pourrait être cryptée avec la clé d’un man-in-the-middle, donc le man-in-the-middle peut accéder à tout, si le chiffrement est inutile sauf pour des observateurs passifs. Utilisateurs confiance SSL pour être sûr, et cela délibérément rendrait il précaires, donc l‘utilisation SSL devienne trompeuse. Si cela doit être utilisé sur un réseau fiable (c’est-à-dire, vous êtes tout à fait à l‘intérieur d’une entreprise contrôlée), puis les certificats auto-signés ne sont pas toujours recommandées. Les deux recommandations dans un réseau de confiance sont simplement utiliser http parce que le réseau lui-même est approuvé, ou d‘obtenir un certificat signé par une autorité de certification (ne pas self-signed). Le réseau est approuvé ou il ne l’est pas.
Les principes décrits ici ne sont pas spécifiques à Apache Cordova, elles s'appliquent à toutes les communications client-serveur.
Lorsque vous exécutez Cordova sur Android, à l‘aide de android:debuggable="true" dans la demande manifeste permettra Erreurs SSL par exemple certificat les erreurs de validation de chaîne sur les certificats auto-signés. Vous pouvez donc utiliser des certificats auto-signés dans cette configuration, mais ce n’est pas une configuration qui doit être utilisée lorsque votre application est en production. Il est destiné à être utilisé uniquement pendant le développement d'applications.
(À DÉTERMINER)