|
Bien que les applications AIR soient créées à l’aide des technologies du Web, il est important pour les développeurs de noter qu’ils ne travaillent pas au sein du sandbox de sécurité du navigateur. Ceci signifie qu’il est possible de créer des applications qui n’endommagent pas le système local, intentionnellement ou non. AIR tente de minimiser ce risque, mais il y a toujours moyen d’introduire des vulnérabilités. La présente rubrique décrit les risques potentiels en matière de sécurité.
Risque lors de l’importation de fichiers dans un sandbox de sécurité de l’application
Les fichiers qui existent dans le répertoire de l’application sont affectés au sandbox de l’application et ils disposent des privilèges du moteur d’exécution au complet. Les applications qui écrivent dans le système de fichiers local devraient plutôt écrire dans
app-storage:/
. Ce répertoire est distinct des fichiers d’application puisqu’il se trouve sur l’ordinateur de l’utilisateur. De ce fait, les fichiers n’étant pas affectés au sandbox de l’application, ils présentent un risque réduit en matière de sécurité. Il est recommandé aux développeurs de tenir compte des éléments suivants :
-
N’incluez un fichier dans un fichier AIR (de l’application installée) que si c’est absolument nécessaire.
-
N’incluez un fichier de programmation dans un fichier AIR (de l’application installée) que si son comportement est bien compris et approuvé.
-
Il ne faut pas écrire ou modifier de contenu dans le répertoire de l’application. Le moteur d’exécution empêche les applications d’écrire ou de modifier des fichiers et des répertoires à l’aide du modèle d’URL
app:/
en renvoyant une exception SecurityError.
-
N’utilisez pas de données, provenant d’une source de réseau, comme paramètres pour les méthodes de l’interface de programmation AIR qui pourraient conduire à une exécution du code. Ce point est également valable pour la méthode
Loader.loadBytes()
et la fonction
eval()
de JavaScript.
Risque lors de l’utilisation d’une source externe pour déterminer des chemins
Une application AIR court un risque lors de l’utilisation de données ou de contenu externes. C’est pourquoi il faut prendre grand soin lors de l’utilisation de données qui proviennent du réseau ou du système de fichiers. C’est en fin de compte le développeur qui est responsable de la fiabilité des connexions réseau établies. Le chargement de données étrangères est toutefois risqué par nature et ne devrait pas être utilisé dans le cadre d’opérations critiques. Les mises en garde suivantes s’adressent aux développeurs :
-
Utilisation de données provenant d’une source du réseau pour déterminer un nom de fichier
-
Utilisation de données provenant d’une source du réseau pour créer une URL à laquelle l’application fait appel pour envoyer des informations de nature privée
Risques lors de l’utilisation, du stockage ou de la transmission d’informations d’identification non sécurisées
Le stockage des informations d’identification de l’utilisateur sur son système de fichiers local introduit par nature un grand risque. Il est recommandé aux développeurs de tenir compte des éléments suivants :
-
Si les informations d’identification doivent être stockées localement, chiffrez-les lorsque vous écrivez dans le système de fichiers local. Le moteur d’exécution fournit, par la classe EncryptedLocalStore, un emplacement de stockage unique pour chaque application installée Pour plus d’informations, voir
Stockage local chiffré
.
-
Ne transmettez pas les informations d’identification de l’utilisateur non chiffrées à une source réseau, à moins que cette source soit fiable et que la transmission utilise le protocole HTTPS: ou Transport Layer Security (TLS).
-
Ne spécifiez jamais un mot de passe par défaut lors de la création d’informations d’identification ; laissez l’utilisateur créer les siennes. Les utilisateurs qui ne modifient pas les éléments par défaut exposent leurs informations d’identification à un attaquant qui connaît déjà le mot de passe par défaut.
Risque d’attaque par rétrogradation de version
Au cours de l’installation de l’application, le moteur d’exécution s’assure qu’une version de l’application n’est pas actuellement installée. Si elle l’est déjà, le moteur d’exécution compare la chaîne de la version à la version en cours d’installation. S’il y a une différence, l’utilisateur peut choisir de mettre à niveau son installation. Le moteur d’exécution ne peut pas garantir que la version nouvellement installée soit plus récente que la précédente, seulement qu’elle est différente. Un attaquant peut distribuer une version antérieure à l’utilisateur pour contourner une faiblesse dans la sécurité. C’est pourquoi il est recommandé au développeur de vérifier la version lorsque l’application est exécutée. Il est également utile que les applications vérifient le réseau pour des mises à jour. Ainsi, même si un attaquant parvient à faire exécuter une version antérieure à un utilisateur, celle-ci se rendra compte qu’elle a besoin d’une mise à jour. De plus, la mise en place d’un modèle de contrôle des versions de l’application clair complique la tâche d’un attaquant qui vise à convaincre un utilisateur d’installer une version antérieure.
|
|
|
