Développement d’applications sécurisées

Les applications du Windows Store utilisant JavaScript permettent aux développeurs d’associer la polyvalence et l’expressivité des technologies Web à un large éventail d’API puissantes disponibles dans Windows Runtime. Cette application possède toute la puissance des applications natives classiques mais elle doit également être sûre. Heureusement, la plateforme a été conçue dans une optique de sécurité. À cet effet, elle inclut plusieurs garde-fous de sécurité qui, lorsqu’ils sont combinés aux meilleures pratiques, simplifient la création d’une application sécurisée.

Sources de données courantes

Les applications du Windows Store ont accès aux nombreuses sources de données qui existent aujourd’hui sur le Web. Chacune de ces sources de données nécessite un traitement sécurisé par les développeurs et doit toujours être validée afin que des scripts malveillants et d’autres contenus dangereux ne puissent pas compromettre l’application.

Vous devez même rechercher et supprimer le code malveillant dans les données provenant d’une source approuvée, telle qu’un service Web principal. En effet, il est possible que les données aient été modifiées lors de leur transit ou que le service principal lui-même ait été compromis. Pour garantir la sécurité de l’application et protéger ses utilisateurs, vérifiez toutes les données que l’application reçoit du réseau.

La première étape pour garantir la sécurité consiste à identifier les points d’arrivée des données dans l’application. Voici quelques sources des données courantes susceptibles de compromettre votre application :

Ce ne sont que quelques exemples de sources de données non approuvées parmi d’autres. La première étape du processus de sécurisation de votre application consiste à répertorier les données provenant du réseau.

Contextes de sécurité et filtrage de scripts

L’infrastructure des applications du Windows Store utilisant JavaScript a été conçue pour aider les développeurs à éviter les problèmes de sécurité courants pouvant résulter du traitement non sécurisé de données non approuvées. Une nouvelle fonctionnalité contribuant à améliorer la sécurité est la prise en charge des contextes Web et des contextes locaux. Ces contextes permettent aux développeurs de concevoir leurs applications intégralement jusqu’à la séparation du contenu non approuvé, tel que du code JavaScript distant, du code et des données approuvés inclus dans le package de l’application.

L’isolement du cadre standard sépare les contextes Web et locaux, ces derniers étant déterminés automatiquement en fonction de l’origine du contenu. Par exemple, le contenu référencé par le biais du protocole ms-appx:// est automatiquement chargé dans un cadre contextuel local, alors que le contenu Web distant chargé par un iframe est toujours chargé dans le contexte Web. Les deux contextes possèdent des propriétés de sécurité et des niveaux d’accès différents (voir Fonctionnalités et restrictions par contexte). Alors que les deux contextes ont des niveaux d’accès différents, des communications intra-cadre pratiques sont disponibles via l’infrastructure postMessage.

Le filtrage de scripts automatique des méthodes DOM bloque le contenu dynamique considéré comme non approuvé et l’empêche d’être injecté dans le DOM, sans toucher toutefois au balisage inoffensif. Si le contenu doit être ajouté à un élément DOM existant, il est plus sûr d’utiliser les propriétés innerText ou outerText à cet effet.

Avertissement de sécurité:  Notez que les scripts de filtrage automatique ne s’appliquent pas quand vous utilisez innerText et outerText pour définir le texte d’un élément script.

Si le filtrage de scripts automatique est un excellent garde-fou contre les les attaques de sécurité inattendues risquant de nuire à l’utilisateur, il ne saurait en aucun cas être la seule défense de votre application. Lorsque le filtrage de scripts automatique bloque le contenu, il lève une erreur qui peut affecter l’expérience utilisateur. De plus, les bibliothèques tierces utilisant des données peuvent solliciter des API qui ne sont pas automatiquement filtrées, ce qui peut générer des problèmes de sécurité. Les meilleures pratiques préconisent de ne utiliser le filtrage de scripts automatique comme le moyen de défense universel et d’effectuer plutôt un filtrage pro-actif dans votre code. Effectuer un filtrage explicite des données non sécurisées est le meilleur moyen de s’assurer qu’une application est sécurisée.

Validation de l’origine des données invokeScriptAsync et postMessage

Les contrôles WebView (XAML) et x-ms-webview (HTML) ont des méthodes semblables à la méthode postMessage pour un iframe qui autorise les communications d’un contexte à un autre. Les méthodes InvokeScriptAsync (XAML) et invokeScriptAsync (HTML) sont le principal moyen pour transférer des données entre les contextes locaux et les contextes Web dans une application du Windows Store.

La méthode postMessage est le principal moyen pour transférer des données entre les contextes locaux et les contextes Web dans une application du Windows Store utilisant une application JavaScript. Au lieu d’utiliser un élément de script ou un outil de piratage entre domaines pour créer des applications Web hybrides (des applications combinant des données provenant de différentes sources sur le Web), utilisez la méthode postMessage. L’utilisation de la séparation fondée sur les cadres entre les sources locales et distantes permet aux développeurs d’intégrer du contenu distant, tel que des cartes ou des annonces, tout en gardant l’accès aux documents et ressources isolé au moyen de la stratégie de la même origine.

Si vous souhaitez utiliser les méthodes postMessage et invokeScriptAsync en toute sécurité pour transférer des messages entre des documents locaux et distants, vérifiez l’origine de la source d’une réponse postMessage ou invokeScriptAsync avant d’utiliser les données. Cette démarche est nécessaire car de nombreuses applications incluent plusieurs éléments iframe ou WebView distants, chacun ayant une origine et un niveau d’approbation différents. En général, une application utilise une fonction de gestionnaire onmessage unique pour chaque page qui traite les messages provenant de tous les éléments iframe ou WebView dans cette page.

L’exemple suivant montre comment appeler la méthode invokeScriptAsync (HTML).


// The application is calling for a specific function inside of the webview
var asyncOp = webView.invokeScriptAsync(“startAnimation”, “500”);
    
asyncOp.oncomplete = function(e){
	// Even though the risk is less with the invokeScript message
	// still make sure not to use eval on the return value.
}

asyncOp.start();



L’exemple suivant montre comment appeler la méthode InvokeScriptAsync (XAML).


async void webview_DOMContentLoaded(WebView sender, WebViewDOMContentLoadedEventArgs args)
{
    var operation = await webview.InvokeScriptAsync("startAnimation", new string[] { "500" });

    if (operation == "success")
    {
        // Handle the message.
    }
} 


Pour améliorer la sécurité des contrôles WebView, nous avons limité le champ d’utilisation de la fonction window.external.notify() à partir de contenu WebView. Ces restrictions empêchent le contenu non approuvé, ou celui ayant été falsifié, d’envoyer des messages exécutés sans validation auprès de l’hôte. Pour que le contenu puisse envoyer des notifications, l’une des conditions suivantes doit être remplie :

  • La source de la page provient du système local via NavigateToString, NavigateToStream ou ms-appx-web:///.
  • La source de la page est remise via https:// et le nom de domaine du site est répertorié dans la section URI de contenu du manifeste de package d’application.
Par exemple :

webview.addEventListener("MSWebViewScriptNotify", handleScriptNotifyEvents);
function handleScriptNotifyEvents(e) {
        if (e.callingUri === "https://msgnotify.example.net/") {
            if(e.value === "msg1")
            {
                // Process the message.);
            }
        }
    }


Cet exemple montre deux versions d’un gestionnaire onmessage : la première version n’est pas sécurisée tandis que la seconde l’est.


// This message handler is not secure because it does not implement an origin check
window.addEventListener('message', function (e) { 
    div.innerHTML = window.toStaticHTML(e.data); 
}, false);

// Secure message handler, validates message domain origin 
window.addEventListener('message', function (e) {
    if (e.origin === 'http://data.contoso.com') { 
        div.innerHTML = window.toStaticHTML(e.data); 
    }
}, false);


En règle générale, une application accepte les messages provenant d’un ou de deux éléments iframe qui envoient des coordonnées de carte ou d’autres contenus d’applications Web hybrides légitimes, mais refuse les contenus des messages provenant d’entités non approuvées, telles que des annonces ou des flux de commentaires. Le filtrage des messages selon l’origine est un moyen efficace pour réduire la surface d’attaque d’une application et s’assurer que les données non approuvées seront rejetées. Veillez à vérifier l’origine des données chaque fois que vous traitez l’événement onmessage.

Filtrage de scripts automatique

Effectuez toujours le filtrage de scripts et la validation sur des sources de données non approuvées. Le mode de validation des données dépend de leur objet. Pour ajouter des données simples et statiques au DOM, utilisez les API DOM qui ignorent les éléments dynamiques. Cette approche permet d’afficher le contenu en toute sécurité, car les scripts ou éléments dynamiques dans les données sont affichés sous forme de texte simple et ne sont pas interprétés comme du code. Vous pouvez utiliser des méthodes, telles createTextNode, pour remplir un élément avec les données non approuvées, qui peuvent ensuite être ajoutées au DOM de document en appelant appendChild ou importNode. Si le contenu doit être ajouté à un élément DOM existant, il est plus sûr d’utiliser les propriétés innerText ou outerText à cet effet.

Cet exemple illustre l’ajout de contenu dynamique de manière non sécurisée.



// Do not use this code.
// Avoid adding untrusted dynamic content
// Unsafe method 1
var myDiv = document.createElement("div");
myDiv.innerHTML = xhr.responseText 
document.body.appendChild(myDiv);

// Unsafe method 2
document.writeln(xhr.responseText);


L’exemple suivant illustre l’ajout de contenu de manière sécurisée :



// Forcing untrusted content into static text is safe

// method 1
var myDiv = document.createElement("div");
myDiv.innerText = xhr.responseText 
document.body.appendChild(myDiv);

// method 2
var myData = document.createTextNode(xhr.responseText);
document.body.appendChild(myData);

// method3
var oDiv = document.getElementById("div1");
oDiv.outerText = xhr.responseText;



Lorsque les données non approuvées contiennent du balisage, utilisez la méthode window.toStaticHTML pour filtrer le balisage dangereux tout en conservant les données sûres.


// The untrusted data contains unsafe dynamic content
var unTrustedData = "<img src='http://www.contoso.com/logo.jpg' on-click='calltoUnsafeCode();'/>";

// Safe dynamic content can be added to the DOM without introducing errors
var safeData = window.toStaticHTML(unTrustedData);

// The content of the data is now 
// "<img src='http://www.contoso.com/logo.jpg'/>" 
// and is safe to add because it was filtered
document.write(safeData);



Ignorer le filtrage de scripts automatique

Les API DOM qui permettent d’injecter du balisage dynamique sont automatiquement filtrées, contrairement aux entrées d’exécution explicites, telles eval, qui ne le sont pas. Vous pouvez utiliser la méthode eval pour ignorer le filtrage automatique et exécuter tout script dynamique que vous savez être sûr. Voici une liste des méthodes d’exécution de scripts que le système ne filtre pas automatiquement pour y rechercher le contenu dangereux :

Étant donné que le système fournit le filtrage automatique à ces méthodes, ne les utilisez pas pour exécuter des données non approuvées sans les avoir préalablement filtrées ou codées vous-même.

L’API MSApp.execUnsafeLocalFunction permet à une fonction d’ignorer le filtrage de scripts automatique qui est normalement appliqué au contenu de balisage dynamique dans le contexte local. Cette méthode est utile si vous souhaitez utiliser une bibliothèque de modèles générant du balisage, telle JQuery, qui sinon serait bloquée par le filtrage automatique.

Comme c’est le cas pour la méthode eval, l’utilisation de MSApp.execUnsafeLocalFunction pour traiter des sources de données non approuvées peut générer des problèmes de sécurité. Les problèmes de sécurité peuvent survenir car les bibliothèques de modèles peuvent, en interne, écrire les données non approuvées dans le document. En cas de doute sur les origines des données, utilisez une bibliothèque de codage sécurisée ou la méthode toStaticHTML pour vous assurer que les données sont débarrassées des éléments et du code nuisibles.

Utilisation d’analyseurs sécurisés

L’utilisation de la méthode eval JavaScript pour générer un objet JavaScript local à partir d’une réponse JSON (JavaScript Object Notation) côté serveur est une pratique de développement Web courante mais néanmoins risquée. Cet exemple illustre l’utilisation de la méthode eval pour traiter des données JSON :


<!DOCTYPE html>
<html>
<head>
</head>
<body>
    <div id="foo"></div>
    <script type="text/javascript">
        var xhr = new XMLHttpRequest();
        xhr.open("GET", "http://contoso.com/json.js", false);
        xhr.onreadystatechange = function () {
            if (xhr.readyState == 4) {
                if (xhr.status == 200) {

			                 // DO NOT USE, UNSAFE
                    var myObject = eval('(' + xhr.responseTxt + ')');
                }
            }
        };
        xhr.send();
     </script>
</body>
</html>


Un problème de sécurité peut survenir si un logiciel malveillant utilise l’écoute clandestine pour modifier les données transférées à la méthode eval. Plutôt que de recourir à cette méthode, utilisez la méthode DOM JSON.parse pour convertir le texte JSON en objet. La méthode JSON.parse rejette tous les scripts, autres que JSON, susceptibles de déclencher une attaque.

L’exemple suivant illustre l’utilisation de la méthode JSON.parse à la place de la méthode eval.


<!DOCTYPE html>
<html>
<head>
</head>
<body>
    <div id="foo"></div>
    <script type="text/javascript">
        var xhr = new XMLHttpRequest();
        xhr.open("GET", "http://remote-server.com/json.js", false);
        xhr.onreadystatechange = function () {
            if (xhr.readyState == 4) {
                if (xhr.status == 200) {
                    var myObject = JSON.parse(xhr.responseText);
                }
            }
        };
        xhr.send();
     </script>
</body>
</html>
</body>
</html>



Protection des données sensibles

Assurez-vous que votre application gère les données sensibles correctement. Pour conserver les données des utilisateurs en toute sécurité, utilisez SSL chaque fois que des données sensibles transitent vers des serveurs distants. Les outils de protection contre les attaques de sécurité sont largement disponibles sur le marché. Considérons que des tiers mal intentionnés vont inévitablement chercher à attaquer les applications n’utilisant pas SSL afin d’intercepter les données privées.

Outre la protection de la confidentialité, SSL présente des avantages pour l’intégrité des applications. SSL empêche les programmes malveillants de modifier les données JSON ou d’autres flux de données réseau. Il est essentiel de protéger l’intégrité du trafic lorsque vous transférez des données réseau aux API Windows Runtime, car celles-ci peuvent accéder au système de l’utilisateur.

Exiger des connexions HTTPS

Il est facile de forcer la transmission et la réception de l’intégralité du contenu distant au moyen du protocole HTTPS (Secure Hypertext Transfer Protocol). Il suffit d’ajouter une balise META HTML à la page de démarrage, comme ceci :


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

L’ajout de cette balise META oblige la navigation non HTTPS à lever une erreur et protège ainsi l’utilisateur contre la modification de la connexion, comme l’empoisonnement de cache DNS (Domain Name System) ou l’usurpation de cache ARP (Address Resolution Protocol).

Les applications du Windows Store utilisant JavaScript prennent en charge le regroupement des certificats privés avec le package d’application pour les développeurs qui ne disposent pas d’une infrastructure à clé publique (PKI).

Utilisation de XDomainRequest

Contrairement aux navigateurs classiques, le script et le balisage locaux dans les applications du Windows Store en JavaScript disposent d’un accès inter-domaines non restreint aux services Web lors de l’utilisation de XMLHttpRequest. Par défaut, XMLHttpRequest envoie des demandes authentifiées par cookie à un site donné lors de l’interaction avec un service Web ou de l’obtention de données JSON. L’utilisation de cookies avec des demandes inter-domaines introduit deux vulnérabilités de sécurité :

  • Si l’application est compromise, les programmes malveillants peuvent accéder aux cookies de tous les sites authentifiés dans le contexte local.
  • L’ensemble du trafic XMLHttpRequest non SSL peut alors être intercepté.

En raison de ces erreurs, utilisez uniquement XMLHttpRequest lorsque l’accès authentifié est nécessaire et qu’il s’agit d’une connexion SSL. Si l’accès authentifié n’est pas nécessaire, utilisez de préférence XDomainRequest. XDomainRequest permet le trafic inter-origines de la même manière qu’un XMLHttpRequest, mais sans utiliser les cookies ou les en-têtes du référent. La sécurité et la confidentialité des demandes inter-domaines sont alors renforcés et l’application est plus sûre.

Restreindre les domaines de navigation

Le domaine de navigation d’une application est défini dans le manifeste de l’application contenu dans le package de l’application. Il est important de limiter la liste des domaines de navigation possibles afin d’éviter que des programmes malveillants réacheminent la session applicative d’un utilisateur vers un domaine qu’ils peuvent contrôler et lancent des attaques d’hameçonnage ou effectuent d’autres activités dangereuses.

Une meilleure pratique recommande d’éviter l’utilisation des caractères génériques lors de l’insertion des URI, car de nombreux sous-domaines de grands services Web offrent la possibilité d’héberger des pages arbitraires ou d’autres contenus auxquels un programme malveillant pourrait s’attaquer. Pour plus d’informations, voir ApplicationContentUriRules.

Utiliser le contrôle WebView dans la mesure du possible

Le contrôle WebView offre davantage de mesures de sécurité qu’un iframe traditionnel. Son utilisation pour héberger du contenu Web réduit par conséquent le risque que du contenu Web arbitraire compromette le code d’application. Le contrôle WebView fournit les mêmes fonctionnalités de sécurité pour les applications du Windows Store en HTML/JavaScript et celles qui utilisent XAML. Grâce à l’utilisation de ApplicationContentUriRules dans le manifeste de package, un développeur peut autoriser les communications entre le contrôle WebView et l’application hôte. Il existe également plusieurs manières de communiquer avec du contenu local. Pour plus d’informations sur les communications, voir Nouveautés de WebView dans Windows 8.1 et Combinaison d’applications et de sites avec x-ms-webview HTML.

Dans la mesure du possible, utilisez l’attribut sandbox HTML5.

L’attribut iframe sandbox HTML5 impose des restrictions supplémentaires sur le contenu d’un iframe. L’application du Windows Store standard utilisant JavaScript fournit certaines protections de sécurité basées sur l’origine du contenu, mais l’attribut sandbox offre une couche de défense supplémentaire. Cet attribut permet aux développeurs de limiter le contenu non approuvé dans une page, comme des annonces ou d’autres contenus arbitraires. L’ajout de l’attribut sandbox empêche le contenu :

  • d’accéder au DOM de la page parent ;
  • d’exécuter des scripts ;
  • d’incorporer des formulaires ;
  • de lire ou d’écrire des cookies ;
  • d’accéder au stockage local ;
  • d’accéder aux bases de données SQL locales.

L’utilisation de l’attribut sandbox pour restreindre l’accès du contenu Web à votre application peut améliorer la sécurité de votre application de façon significative.

Rubriques associées

Fonctionnalités et restrictions par contexte
Inspection de votre gadget
Bibliothèque Anti-Cross-Site Scripting Library
postMessage
invokeScriptAsync (HTML)
InvokeScriptAsync (XAML)

 

 

Afficher:
© 2014 Microsoft