Méthodes conseillées en matière de sécurité pour créer des applications du Windows Store

Lors de la création de la plateforme destinée aux applications du Windows Store, l'un de nos principaux objectifs était de faire en sorte que les clients puissent faire confiance aux applications. Nous voulons que les clients sachent que leurs applications fonctionneront comme prévu, qu'elles coexisteront aux côtés des autres applications et qu'elles se désinstalleront proprement. Cette confiance provient de différentes sources : de l'intégration du Windows Store à l'installation et à la désinstallation sans contraintes en passant par l'autorisation d'utiliser votre emplacement et webcam et par le Kit de certification des applications Windows qui permet de vérifier que votre application répond aux critères de transfert dans le Windows Store. La confiance des clients ne repose pas sur une seule fonction, un seul processus ou une seule qualité. Elle s'appuie sur la somme de différents facteurs afin que les clients aient toute confiance dans l'intégralité du processus. Nous avons décrit notre approche plus en détail dans le billet Concevoir des applications de style Metro fiables et dignes de confiance.

Nous souhaitons maintenant aborder de façon spécifique les applications sûres et sécurisées et expliquer comment faire en sorte que les clients aient confiance en votre application. Les applications actuelles renferment souvent des données client importantes, qu'il s'agisse de renseignements financiers ou de photos personnelles irremplaçables. Pour de nombreux clients, ces données constituent leur moyen d'existence et il est primordial que les applications préservent la sécurité de ces données. Même pour les applications contenant des données minimales, les clients veulent qu'elles fonctionnent comme prévu, sans interférer avec les autres applications.

L'implémentation des méthodes conseillées en matière de sécurité dans votre application est essentiel pour gagner la confiance des clients et assurer leur satisfaction sur le long terme. Heureusement, les méthodes conseillées courantes en matière de sécurité sont simples et il n'est pas difficile de renforcer la sécurité de votre application. Les applications fonctionnent également dans le contexte d'un conteneur d'application unique qui contribue à isoler l'application et ses données des autres applications. Les conteneurs d'application offrent un environnement dédié à votre application, y compris votre propre banque de données et de paramètres.

Windows 8 et Visual Studio 2012 fournissent un ensemble d'API, de contrôles et d'outils qui visent à réduire les vulnérabilités potentielles des applications et à résoudre les problèmes de sécurité les plus fréquents. Même si aucune plateforme n'est parfaite, nous sommes convaincus que l'association de différents éléments vous permettra de créer de formidables applications et que la plateforme continuera à s'améliorer au fil du temps. Dans ce billet, nous abordons plusieurs conseils et méthodes conseillées qui vous permettront d'optimiser vos applications et de renforcer la sécurité des clients.

Commençons !

Conseil n° 1 : compilez avec Visual Studio

À partir de Windows 8, nous avons activé par défaut un certain nombre de méthodes conseillées existantes en matière de sécurité, pour lesquelles vous n'avez rien d'autre à faire que compiler votre application avec Visual Studio 2012. Lorsque vous compilez avec Visual Studio 2012, les technologies de sécurité qui protègent vos applications des attaques les plus courantes (/GS, ASLR, DEP et SeHOP) sont maintenant activées par défaut pour le code natif au sein de votre application.

Conseil n°2 : minimisez les fonctionnalités de l'application

Chaque application peut déclarer des fonctionnalités qui définissent la manière dont l'application interagit avec différents périphériques et ressources. Il est important de définir l'ensemble minimal de fonctionnalités dont votre application a besoin, afin qu'elle s'exécute selon le principe des privilèges minimum nécessaires. À l'aide d'un ensemble minimal de fonctionnalités, vous rendez votre application moins vulnérable aux attaques.

Ainsi, la fonctionnalité Réseaux domestiques et professionnels permetà une application d'accéder à des ordinateurs sur un réseau local, par exemple pour des jeux pair à pair. Cette fonctionnalité peut également être utile pour effectuer des tests préalables à la commercialisation avec un service local, mais se révèle souvent superflue et risque d'exposer l'application aux attaques d'un réseau local non fiable, tel qu'un point d'accès sans fil dans un café ou un aéroport. Il est préférable de supprimer la fonctionnalité et d'effectuer les tests avec un serveur distant, qui présente en outre l'avantage de répliquer les conditions du monde réel pour votre application. Si vous utilisez toutefois la fonctionnalité Réseaux domestiques et professionnels, n'oubliez pas de la supprimer avant de transférer votre application pour la certification du Windows Store.

Une application avec un ensemble minimal de fonctionnalités : l'accès à Internet seulement !

Notez que les fonctionnalités Authentification en entreprise, Certificats utilisateur partagés et Bibliothèque de documents sont conçues pour l'accès d'entreprise et les documents incorporés (par exemple, l'ouverture d'un document qui nécessite l'ouverture d'un autre document à l'intérieur) et qu'un compte d'entreprise est nécessaire pour transférer une application avec ces fonctionnalités dans le Windows Store. Ces fonctionnalités ne sont généralement pas requises pour la plupart des applications, mais peuvent être nécessaires pour des applications professionnelles qui doivent accéder à des ressources d'entreprise. Ces fonctionnalités sont très limitées et leur utilisation fait l'objet de vérifications supplémentaires de la part de l'équipe du Windows Store.

Conseil n°3 : utilisez le sélecteur de fichiers au lieu des fonctionnalités de la bibliothèque

En vous appuyant sur le conseil n°2 de réduction des fonctionnalités, vous pouvez souvent supprimer tout à fait les fonctionnalités basées sur les fichiers. Si votre application n'a besoin d'accéder qu'à un petit nombre de fichiers, autorisez l'utilisateur à sélectionner ses fichiers avec un sélecteur de fichiers. Le sélecteur de fichiers simplifie le code de votre application et permet à l'utilisateur de trouver exactement ce dont il a besoin plus facilement, sans fonctionnalités supplémentaires. Le sélecteur de fichiers étant identique dans toutes les applications, les utilisateurs reconnaîtront immédiatement la boîte de dialogue lorsqu'ils utiliseront votre application pour la première fois et pourront revenir rapidement dans votre application une fois leur sélection faite.

  Sélecteur de fichiers présentant la bibliothèque d'images

En JavaScript 

var picker = new Windows.Storage.Pickers.FileOpenPicker();
openPicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail;
picker.fileTypeFilter.replaceAll([".png", ".jpg", ".jpeg"]);
picker.suggestedStartLocation =  
   Windows.Storage.Pickers.PickerLocationId.picturesLibrary;

En C#

using Windows.Storage;
using Windows.Storage.Pickers;

FileOpenPicker openPicker = new FileOpenPicker();
openPicker.ViewMode = PickerViewMode.Thumbnail;
openPicker.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
openPicker.FileTypeFilter.Add(".png");
openPicker.FileTypeFilter.Add(".jpg");
openPicker.FileTypeFilter.Add(".jpeg");

Pour illustrer le caractère approprié des fonctionnalités, si votre application permet à un utilisateur de sélectionner une image, il doit utiliser le sélecteur de fichiers au lieu de la fonctionnalité Bibliothèque d'images. Si votre application a besoin d'un accès total par programme à une bibliothèque, par exemple pour un lecteur de musique qui lit le contenu de la bibliothèque musicale, il est alors judicieux d'accéder à la bibliothèque musicale avec une fonctionnalité. Si votre application a besoin d'accéder à des documents, utilisez toujours le sélecteur.

Conseil n°4 : ne faites pas confiance aux données distantes

Pour les applications écrites en JavaScript, il est primordial de vérifier et de gérer attentivement le contenu Web non fiable. Les pages HTML incluses avec l'application s'exécutent en général dans le contexte local de l'application, qui permet l'accès à Windows Runtime. Les pages distantes affichées au sein d'un élément iframe s'exécutent dans le contexte Web de l'application et n'ont pas accès à Windows Runtime. Il est essentiel de savoir qui appelle Windows Runtime au sein de votre application. Après tout, vous ne voulez certainement pas qu'un site Internet inconnu prenne le contrôle de votre application ? (Réponse : Non, ce ne serait pas une bonne idée.) Votre application doit éviter d'appeler les API qui exécutent du script, tel qu'eval(), setTimeout() et setInterval() sauf si vous savez que l'entrée de l'API prend sa source dans votre package. Si vous avez besoin d'utiliser ces API, n'oubliez pas qu'elles peuvent évaluer le script et que vous devez par conséquent savoir exactement comment le script est construit si vous transmettez des données à ces API.

Si vous utilisez des données JSON, utilisez JSON.parse au lieu d'eval(), qui est beaucoup plus sûr et n'expose pas votre application au risque d'attaque par injection de script.

En JavaScript 

var jsontext = '{"firstname":"Aaren","surname":"Ekelund"}';
var contact = JSON.parse(jsontext);
console.log(contact.surname + ", " + contact.firstname);

// Output: Ekelund, Aaren

Enfin, le contenu Web inconnu utilisé au sein de l'application doit également être expurgé pour supprimer le contenu exécutable avec innerText ou toStaticHTML. Ce processus de nettoyage supprime ou désactive le script qui affiche le contenu Web au sein de votre application.

En JavaScript

div.innerHTML = window.toStaticHTML(data);
div.innerText = data; 

Ces fonctions permettent de s'assurer que le script non fiable ou le contenu dangereux ne peut pas s'exécuter au sein de votre application. Dans le premier cas, le script est éliminé et dans le second cas, le contenu est transformé en texte non exécutable. Même si la plupart des applications accèdent au contenu Web via les champs de saisie de l'application et les API traditionnelles, telles qu'un objet XMLHttpRequest, n'oubliez pas que le contenu Web peut également emprunter d'autres chemins, par exemple l'icône Partager.

Conseil n°5 : ne laissez pas le Web accéder à WinRT

Par défaut, Windows 8 autorise uniquement le contenu de votre package d'application à accéder à Windows Runtime (WinRT). Si votre application accepte des entrées ou des données du Web, ne laissez pas ces données contrôler l'usage que fait votre application des API WinRT. Vos clients attendent d'une application qu'elle se comporte comme prévu et ils veulent que votre application réponde à cette attente. Si vous utilisez un site Web, vous pouvez afficher le site dans un élément iframe sandbox, ce qui permet d'empêcher le script, la validation de formulaire et tout autre contenu de s'exécuter dans votre application.

Si votre application exécute du contenu provenant du Web, ce contenu peut ensuite accéder aux paramètres et données de votre application ou aux fichiers auxquels votre application peut également accéder. Ceci est particulièrement critique pour les applications écrites en JavaScript, dans lesquelles il est beaucoup plus facile d'exécuter du script à la volée. Par exemple, si vous possédez une application écrite en JavaScript qui utilise postMessage pour transmettre des données à une API ou à un code empaqueté, vérifiez bien l'origine des données pour vous assurer qu'elles proviennent d'une source fiable.

En JavaScript

window.attachEvent('onmessage',function(e) {
if (e.origin == 'https://www.contoso.com/') {
…
    }
});

Pour plus d'informations sur l'ajout de contenu Web à une application écrite en JavaScript, consultez l'application d'exemple sur l'intégration de contenu et de contrôles à partir de services Web.

Conseil n°6 : demandez une preuve : authentifiez votre application et vos clients

Les applications basées sur le cloud, dont une partie accède aux services du cloud, sont extrêmement puissantes, mais doivent faire preuve de prudence lors de l'authentification auprès des services cloud afin d'éviter les abus. Les services cloud qui acceptent les entrées utilisateur doivent toujours identifier et authentifier les utilisateurs et l'application. En authentifiant l'application et l'utilisateur avec un service cloud fiable, vous savez que quelqu'un utilise en toute légitimité votre service avec l'application exacte correspondante. Le fait de connaître l'identité de l'utilisateur présente un autre avantage : en cas d'abus, vous pouvez facilement identifier et supprimer tout le contenu publié par cet utilisateur.

Vous pouvez authentifier l'application avec GetAppReceiptAsync pour vérifier que l'application provient du Windows Store et qu'elle dispose d'une réception valide du Windows Store. Si vous possédez un serveur principal, vous pouvez confirmer le certificat public de la signature de réception en vous connectant à l'URL suivante, où <CertificateId> est le CertificateId inclus avec la réception.

https://go.microsoft.com/fwlink/p/?LinkId=246509&cid=<CertificateId>

WinRT offre aux applications clientes différentes méthodes pratiques pour authentifier l'utilisateur d'un service cloud, notamment le service Broker d'authentification Web (pour l'authentification de style OAuth), le stockage sécurisé des informations d’identification (pour le stockage des mots de passe et des valeurs chiffrées limitées) et les magasins de certificats partagés (pour l'authentification des certificats des clients). Toutes ces formidables options permettent de gagner la confiance des clients vis-à-vis de votre gestion de l'authentification et de leurs informations d'identification.

Conseil n°7 : validez les fichiers, les protocoles et les données importées

De nombreuses applications créent et chargent des fichiers, autorisent l'activation via un protocole ou fournissent une méthode d'importation des données. Tout comme le contenu Web distant décrit ci-dessus, il est possible que le format de ces données soit incorrect ou que ces données proviennent de sources moins dignes de confiance et qu'elles ne doivent pas être approuvées. Les applications qui ouvrent des fichiers, qui importent des données ou qui acceptent du contenu partagé doivent valider le contenu avant de l'utiliser.

La validation dépend du type d'entrée et de la manière dont l'application utilise ce contenu (processus qui peut être simple comme complexe). Par exemple, une entrée utilisée par une requête de base de données doit être validée pour empêcher une attaque par injection de code SQL, car les bases de données exécutent généralement toutes les requêtes valides qu'elles reçoivent, et peuvent divulguer, manipuler ou même supprimer des données contenant une entrée malveillante.

Les fichiers, les protocoles, les données importées et le contenu partagé peuvent inclure du contenu non fiable qui peut ne pas correspondre aux attentes de votre application. Les fichiers et protocoles sont la forme la plus courante d'entrée non fiable, mais soyez également prudent en ce qui concerne le Presse-papiers et lors de l'acceptation de contenu provenant de l'icône Partager, car les clients peuvent importer de leur navigateur Web du contenu non fiable sous n'importe quelle forme ou presque. Les applications qui renferment des données confidentielles, telles que les applications financières personnelles, doivent faire preuve d'une extrême prudence envers le contenu non fiable, car elles ont accès à des informations particulières précieuses aux yeux des clients.

Conseil n°8 : utilisez les connexions HTTPS

En cas de doute, utilisez le chiffrement ! Les connexions HTTPS permettent de s'authentifier sur un serveur distant et sont fortement recommandées pour prévenir les attaques de l’intercepteur. Même si ces attaques ne constituent pas un problème sur votre réseau domestique, il existe toujours de nombreux réseaux sans fil non chiffrés à travers le monde sur lesquels une connexion HTTP n'est pas sécurisée.

Pour une connexion HTTPS standard, le site Web distant doit posséder un certificat fourni par une autorité de certification et être configuré de façon à autoriser une connexion HTTP. À partir de Windows 8, une application peut bénéficier des connexions SSL avec un certificat auto-signé pour s'authentifier en toute sécurité sur votre serveur principal. Cela signifie que vous pouvez disposer d'une connexion HTTPS sécurisée, même sans certificat fourni par une autorité de certification. Si vous évitiez HTTPS en raison du coût, il n'est pas justifié de livrer une application qui transmet des données par le biais de connexions HTTP non sécurisées.

Pour utiliser un certificat auto-signé, vous pouvez simplement ajouter une déclaration de certificatà votre application via le concepteur du manifeste dans Visual Studio 2012, ou directement dans le code XML du manifeste de votre application. Vous devez également configurer votre serveur principal pour qu'il utilise le même certificat ; pour IIS, une procédure simple permet de créer et de configurer votre site Web. Votre application utilise ensuite automatiquement le certificat empaqueté pour authentifier la connexion sur votre serveur Web.

Et enfin, si vous possédez une application écrite en JavaScript, vous pouvez également demander des connexions HTTPSà l'aide de la balise <meta> suivante dans votre application :

<meta name="ms-https-connections-only" content="true"/>

Développer la confiance

Nous espérons que vous êtes satisfait des opportunités offertes par Windows 8 et que vous concevez de formidables applications qui seront bientôt disponibles dans le Windows Store. Les conseils et méthodes conseillées que nous avons abordés ci-dessus constituent un élément clé pour proposer une expérience plus sûre et sécurisée à vos clients, afin que vos applications leur inspirent pleinement confiance. La sécurité fait partie des attentes envers toutes les applications, que ce soit pour préserver des scores élevés obtenus de haute lutte ou des données financières confidentielles.

Les applications Windows 8 et du Windows Store ont été conçues pour que les clients puissent les essayer et les acheter en toute confiance, de façon très simple, grâce aux investissements collectifs que nous avons consentis dans la plateforme d'applications. Nous sommes convaincus que la plateforme d'applications est idéale pour créer des applications dignes de confiance que les utilisateurs apprécient.

Si vous souhaitez en savoir plus sur la sécurité des applications, consultez le livre blanc Développement d'applications sécurisées, Starter Kit for the Security Development Lifecycle et le Centre Sécurité pour connaître les dernières informations.

Merci !

--Scott Graham, chef de projet senior, Windows

--Crispin Cowan, chef de projet senior, Windows

--David Ross, ingénieur principal de sécurité informatique, Fiabilité de la sécurité informatique