Share
La sécurité est un sujet qui revient de temps en temps. Ce n'est pas un problème depuis le début, mais quand quelque chose de mauvais arrive, on le considère généralement comme responsable. Le logiciel est complexe, la programmation humaine de la machine est loin d'être parfaite et l'utilisateur peut ne pas suivre les meilleures pratiques. Alors, comment pouvons-nous créer un système sécurisé?
Le Web est l’un des endroits les moins sûrs possible. Ordinateurs présentant des risques de sécurité potentiels connectés les uns aux autres. Serveurs pouvant recevoir des données arbitraires. Clients qui exécutent du code à partir de sources inconnues. Bien que nous ne puissions pas contrôler la sécurité des serveurs, nous devons faire quelque chose pour protéger les clients. Même si JavaScript peut être considéré comme un langage de script sécurisé, le code de tous les plugins ActiveX, Flash ou Silverlight ne l'est certainement pas. De plus, même si JavaScript est un sandbox, il peut être utilisé de manière à ce que l'utilisateur puisse déclencher des actions non sécurisées..
Dans ce tutoriel, nous verrons le modèle de sécurité Web en action. Nous aborderons les meilleures pratiques et les directives générales pour la création d’applications Web sécurisées. Nous allons apprendre quelle est la politique de partage des ressources d'origine croisée et comment nous pouvons la contrôler. Enfin, nous parlerons également du contenu (externe) du bac à sable.
L’une des recommandations les plus importantes n’a rien à voir directement avec HTML: utilisez HTTPS! La relation avec HTML réside bien entendu dans la distribution de nos documents hypertextes. Néanmoins, nous devons comprendre que l'utilisation de HTTPS pour le transport de notre document et l'utilisation de HTTPS pour nos ressources sont deux choses différentes. Il faut absolument vérifier si toutes les ressources contenues utilisent réellement le https: // schème.
Une autre directive importante concerne le contenu défini par l'utilisateur. Une fois que nous autorisons les utilisateurs à saisir des données sur un formulaire, nous devons faire attention. Nous devons non seulement nous assurer que le serveur Web est protégé contre les attaques courantes, telles que l'injection SQL, mais également que les données stockées ne sont pas utilisées sans précaution dans le code exécutable. Par exemple, nous devrions échapper des chaînes pour ne contenir aucun code HTML. HTML seul n'est pas malveillant, mais il peut déclencher l'exécution de scripts ou la récupération de ressources. Une façon de permettre aux utilisateurs d'écrire du HTML, qui sera placé sur la page de sortie sans modification, consiste à répertorier certaines balises et attributs. Les autres éléments seront échappés.
Nos scripts Java devraient également minimiser l'exposition et la confiance envers les bibliothèques tierces. Bien sûr, nous utilisons l'expression de fonction immédiatement invoquer (IIFE) pour empêcher la pollution du contexte global; Cependant, une autre raison est de ne pas divulguer (probablement) des états internes cruciaux, qui peuvent ensuite être modifiés volontairement ou par hasard par d'autres scripts..
(function () // Code standard ici.) ();
Pour nous, c’est certainement une bonne pratique de s’appuyer sur 'use strict'; et les avantages véhiculés. Néanmoins, limiter le script en cours d'exécution ne nous empêche pas d'utiliser des API avec des données potentiellement corrompues. Cookies et contenu dans le stockage local peut être modifié ou visualisé par l'utilisateur ou d'autres programmes en fonction de conditions sur lesquelles nous ne pouvons influer. Nous devrions donc toujours mettre en œuvre des contrôles de cohérence, qui nous donnent un indice pour détecter les défauts d’intégrité dès que possible..
Enfin, nous devons nous assurer que nous utilisons uniquement des ressources tierces approuvées. L'utilisation de scripts provenant d'autres serveurs de notre site permet de modifier la page ou de violer la vie privée de nos utilisateurs..
Le concept de partage de ressources d'origine croisée (CORS) est simple. Le navigateur n'autorise pas l'intégration de ressources spéciales d'origines différentes, à moins que les origines ne le permettent explicitement. Les ressources spéciales peuvent être, par exemple, des polices Web ou tout autre élément demandé via un XMLHttpRequest. Les requêtes AJAX d'origine croisée sont interdites par défaut en raison de leur capacité à exécuter des requêtes avancées présentant de nombreux problèmes de sécurité liés aux scripts..
L'origine est fondamentalement définie via la combinaison de protocole, d'hôte et de port utilisée. Donc http://a.com est différent de https://a.com, qui est différent de https://a.com:8080. Ils sont tous différents de http://b.com.
Les clients peuvent être autorisés à utiliser des ressources en incluant un certain en-tête dans la réponse. Le navigateur détermine ensuite si le site Web actuel est autorisé à utiliser la ressource ou non. L'origine est généralement déterminée via le domaine du site actuel.
Regardons un exemple illustratif. Dans ce qui suit, nous supposons que notre page est située à foo.com. Nous demandons des données JSON à partir d'une page hébergée sur bar.com. Pour la requête JSON, nous utilisons le XMLHttpRequest comme indiqué ci-dessous.
Accentsconagua
var xhr = new XMLHttpRequest (); xhr.open ('GET', 'https://bar.com/users'); xhr.addEventListener ('load', fonction (ev) if (xhr.status === 200) var result = JSON.parse (xhr.responseText); //…, false); xhr.send (); Le navigateur prévoit déjà la possibilité d’une réponse compatible CORS en ajoutant le Origine en-tête de la demande:
Origine: http://foo.com
Maintenant, le serveur doit fournir la bonne réponse. Non seulement nous voulons que le bon JSON soit transporté, mais nous avons surtout besoin d’en-têtes spécifiques à CORS. Il est possible d'utiliser des caractères génériques. Par exemple, l’exemple suivant accordera le droit d’utiliser la ressource demandée à toute requête..
Access-Control-Allow-Origin: *
CORS peut également être utilisé comme alternative à la solution de contournement JSONP. JSONP utilise des scripts pour créer des requêtes AJAX d'origine croisée donnant lieu à des réponses JSON. Avant la SCRO, les appels entre domaines étaient généralement interdits, mais l'inclusion de scripts de différents domaines était toujours acceptable. Dans la plupart des API, une réponse JSONP a été déclenchée en fournissant un paramètre de requête spécial, nommant la fonction de rappel..
Supposons l'appel à http://bar.com/api entraîne la réponse JSON suivante:
"nom": "exemple", "facteur": 5, "actif": vrai
L’appel JSONP à, par exemple., http://bar.com/api?jsonp=setResult nous donnerait:
setResult ("name": "exemple", "facteur": 5, "actif": vrai); Le résultat de JSONP n’est visible que par le >XMLHttpRequest objet.
Une solution idéale ne retomberait que sur JSONP pour les navigateurs existants, tout en adoptant CORS pour les navigateurs plus récents. Cela évitera de nombreux problèmes de script intersite (XSS) provenant de sites externes compromis. Incorporer des scripts à partir de pages externes a toujours été une activité risquée. Une solution encore meilleure consisterait à rediriger la demande JSON de notre serveur vers la machine cible. De cette façon, nous discutons avec notre serveur (de confiance), qui obtient la réponse de la cible, évalue sa santé et renvoie le résultat (valide)..
Chaque document vient avec son propre la fenêtre. Accéder à cette la fenêtre est principalement proxy au la fenêtre du contexte de navigation actuel, qui entraîne l'onglet que nous voyons. Le contexte de navigation est créé avec plusieurs options, telles que le contexte parent, le créateur et la page initiale. Outre ces options, des indicateurs de sécurité sont définis. Les indicateurs définissent les capacités et les restrictions du contexte. En effet, il est possible d'empêcher certains comportements, tels que l'exécution de scripts ou l'ouverture de nouveaux onglets.
Comment pouvons-nous définir les indicateurs de sécurité d'un nouveau contexte? Nous définissons le contexte via des attributs attribués aux éléments, qui doivent créer un nouveau contexte. Actuellement, seuls les iframe Cet élément a cet attribut, même si les cadres standard s’inscriraient également dans la description précédente. Cependant, les cadres standard sont considérés comme obsolètes et ne sont donc pas vraiment pris en charge. Même si le standard HTML5 les mentionne, ils ne doivent plus être utilisés.
Il y a un tas de drapeaux disponibles. Les plus importants sont:
permettre-top-navigation (permet de changer le contexte du haut)autoriser les plugins (permet intégrer, objet,…)permettre-même-origine (le contenu de la même origine peut être consulté)permettre-formes (les formulaires peuvent être soumis)autoriser les popups (les popups / nouveaux contextes ne seront pas bloqués)autoriser le verrouillage du pointeur (active l'API de verrouillage du pointeur)permettre-scripts (permet l'exécution de script)le Les iframes en bac à sable peuvent être utilisés pour de nombreuses tâches. Par exemple, si nous voulons évaluer les scripts en toute sécurité, nous pouvons transmettre le contenu à évaluer à un gestionnaire spécial assis dans un L'implémentation exacte nécessite également une messagerie HTML5 entre les documents. Nous envoyons la demande d'évaluation avec le Nous pouvons également mettre en sandbox des parties de la page en cours en utilisant la politique de sécurité du contenu (CSP). Cette propriété est généralement transportée via les en-têtes HTTP de la page, mais HTML nous donne la possibilité de la définir dans un fichier. Un exemple ressemble à ce qui suit. Nous devons utiliser le droit Les différentes définitions (appelées stratégies) acceptent également les caractères génériques. Le but exact et l'apparence dépendent fortement de la politique utilisée. La sécurité Web est possible, même si elle est difficile à atteindre et dépend de nombreux paramètres externes (souvent impossibles à contrôler). Si nous pouvons minimiser ces paramètres externes, tels que le contenu ou les scripts insérés, nous sommes généralement en bonne forme. La plupart des vecteurs d'attaque ne peuvent être utilisés qu'à partir de scripts. Nous avons vu que les cadres (en ligne) et les hyperliens peuvent être ajustés avec les drapeaux en sandbox. Nos propres ressources ne devraient être déployées que dans le respect de la SCRO. iframe. Le gestionnaire appellerait le eval une fonction. Le cadre en ligne est mis en sandbox pour n'autoriser que les scripts, rien d'autre. Aucune fenêtre contextuelle ne peut être ouverte, la navigation ne peut pas être utilisée et tout notre DOM est séparé.postMessage méthode et écouter la réponse via le message un événement. étiquette.http-equiv valeur. Le contenu est une série de définitions spécifiques à la page..
Conclusion
Références
