Share
Grâce à HTML5, de plus en plus de la logique d'une application est transférée du côté serveur au côté client. Cela nécessite que les développeurs front-end se concentrent davantage sur la sécurité. Dans cet article, je vais vous montrer comment sécuriser davantage vos applications. Je vais me concentrer sur des techniques dont vous n'avez peut-être pas entendu parler, au lieu de simplement vous dire que vous devez échapper aux données HTML entrées par les utilisateurs..
Bien sûr, je ne veux pas que vous serviez votre contenu avec FTP ou TCP simple. Ce que je veux dire, c'est que si vous voulez que vos utilisateurs soient en sécurité lors de l'utilisation de votre site Web, vous devez utiliser SSL (HTTPS). Et pas seulement pour les sites de connexion, ou des informations précieuses. Pour tout votre contenu. Sinon, lorsque quelqu'un accède à votre application depuis un réseau public, ce qu'il voit peut être malformé par un pirate informatique interne à ce réseau. Ceci s'appelle une attaque principale dans le milieu:
Lorsque vous utilisez SSL, toutes les données sont cryptées avant leur envoi. Ainsi, même si l'attaquant les récupère, il ne pourrait ni les modifier ni les capturer. C’est de loin l’étape la plus importante pour sécuriser votre application..
Cet en-tête HTTP peut s'avérer utile si vous souhaitez diffuser votre contenu en utilisant uniquement SSL. Quand il est émis par le serveur (ou un balise, mais cela permettra à au moins une requête d'être HTTP), aucun trafic non sécurisé ne viendra du navigateur vers votre serveur. Il est utilisé comme ceci:
Strict-Transport-Security: max-age = 3600; includeSubDomains
le includeSubDomains partie est facultative, elle vous permet de déclarer que vous souhaitez également que tous les sous-domaines soient accessibles via HTTPS. le max-age L'option définit combien de temps (en secondes) les pages doivent être servies à l'aide de SSL. Malheureusement, seuls Firefox, Chrome et Opera prennent en charge Strict Transport Security..
Un autre moyen d'améliorer encore la sécurité sur HTTP et HTTPS consiste à utiliser ces deux attributs de cookie: Garantir et HttpOnly. Le premier permet l'envoi d'un cookie uniquement sur une connexion SLL. Le second peut sembler exactement le contraire, mais ce n’est pas le cas. Il indique au navigateur que le cookie est uniquement accessible via le protocole HTTP (S). Il ne peut donc pas être volé à l'aide, par exemple, du code JavaScript. document.cookie.
La politique de sécurité du contenu vous permet de définir l’origine de tous les scripts, images, etc. de votre site..
Si vous pensez que votre filtre XSS arrêtera toutes les attaques XSS possibles, vérifiez le nombre de façons de réaliser ces attaques et réfléchissez-y à nouveau. Bien sûr, sécuriser votre application pour qu'elle arrête toutes ces situations peut être un problème et peut le ralentir, mais il existe une solution.
C'est ce qu'on appelle la politique de sécurité du contenu. Il vous permet de définir l’origine de tous les scripts, images, etc. de votre site. Il bloque également tous les scripts et styles en ligne. Ainsi, même si quelqu'un peut injecter une balise de script dans un commentaire ou une publication, le code ne sera pas exécuté. Le CSP est un en-tête HTTP (qui peut également être défini à l'aide de HTML tag), qui ressemble à ceci:
Content-Security-Policy: politique
Où politique est un ensemble de directives CSP. Voici les options possibles:
Si aucune directive n'est définie, le navigateur suppose que toutes les origines sont autorisées. Ceci peut être changé en réglant la default-src option. Ce que vous définissez ici sera appliqué à toutes les directives non définies. Il y a aussi bac à sable option, ce qui rend la page Web charger comme un iframe avec le bac à sable attribut. Un exemple d'utilisation de l'en-tête CSP ressemblerait à ceci:
Content-Security-Policy: default-src: 'self'; script-src: https://apis.google.com;
Il permet à tous les actifs d’être chargés uniquement à partir de l’origine de l’application (le 'soi' attribut) et vous permet également de charger des scripts à partir du serveur des API Google. La définition de CSP offre beaucoup de souplesse et, utilisée correctement, elle améliorera considérablement la sécurité de votre page Web..
La chose à retenir lors de l'utilisation de CSP est que, par défaut, tout le JavaScript en ligne ne sera pas exécuté. Cela comprend également:
Accentsconagua
javascript URL: comme En effet, le navigateur ne peut pas distinguer votre code en ligne du code en ligne du pirate. Vous devrez les remplacer en ajoutant des écouteurs d’événement avec addEventListener ou équivalent d'un cadre. En fin de compte, ce n'est pas une mauvaise chose, car cela vous oblige à séparer la logique de votre application de sa représentation graphique, ce que vous devriez faire de toute façon. CSP bloque également (par défaut) tout eval ()-Code ish, y compris les chaînes dans setInterval/setTimeout et un code comme nouvelle fonction ('return false').
CSP est disponible dans la plupart des navigateurs modernes. Firefox, Chrome et Opera (mobile également) utilisent le standard Contenu-Sécurité-Politique entête. Safari (iOS aussi) et Chrome pour Android utilisent le X-WebKit-CSP entête. IE10 (avec un soutien limité uniquement à la bac à sable directive) utilise X-Content-Security-Policy. Ainsi, grâce à Internet Explorer, vous ne pouvez pas utiliser uniquement le CSP (à moins d'utiliser Google Chrome Frame), mais vous pouvez toujours l'utiliser pour améliorer la sécurité des navigateurs réels et préparer votre application pour l'avenir..
JSONP est actuellement la technique la plus utilisée pour obtenir des ressources d'autres serveurs malgré la politique de même origine. Généralement, vous créez simplement la fonction de rappel dans votre code et transmettez le nom de cette fonction à l'URL à partir de laquelle vous voulez obtenir les données, comme ceci:
fonction parseData (data) …
Mais en faisant cela, vous créez un risque important pour la sécurité. Si le serveur sur lequel vous récupérez des données est compromis, un pirate informatique peut ajouter son code malveillant et, par exemple, voler les données personnelles de votre utilisateur, car en réalité, vous obtenez JavaScript en utilisant cette demande - et le navigateur exécutera tout le code juste comme avec un fichier de script normal.
La solution ici est le partage de ressources d'origine croisée. Il permet à votre fournisseur de données d’ajouter un en-tête spécial dans les réponses afin que vous puissiez utiliser XHR pour extraire ces données, puis les analyser et les vérifier. Cela supprime le risque d'obtenir du code malveillant exécuté sur votre site.
L'implémentation nécessite que le fournisseur ajoute uniquement l'en-tête spécial suivant dans les réponses:
Access-Control-Allow-Origin: origines autorisées
Il peut s’agir de quelques origines autorisées séparées par des espaces ou d’un caractère générique: * laisser chaque origine demander les données.
Toutes les versions actuelles des navigateurs modernes prennent en charge CORS, à l’exception de Opera Mini..
Bien sûr, le plus gros problème ici est que les fournisseurs de services doivent ajouter le support CORS, de sorte que cela ne dépend pas complètement du développeur..
Un iframe avec le
bac à sablel'attribut ne pourra pas naviguer dans la fenêtre, exécuter des scripts, verrouiller le pointeur, afficher des fenêtres contextuelles ou envoyer des formulaires.
Si vous utilisez des iframes pour charger du contenu à partir de sites externes, vous pouvez également les sécuriser. Cela peut être fait en utilisant le bac à sable attribut iframe. Un iframe avec un tel attribut vide (mais présent) ne sera pas autorisé à naviguer dans la fenêtre, à exécuter des scripts, à verrouiller le pointeur, à afficher des fenêtres contextuelles ou à envoyer des formulaires. Le cadre aura également une origine unique, donc il ne peut pas utiliser stockage local ou tout ce qui est lié à la politique de même origine. Vous pouvez bien sûr autoriser certaines d’entre elles, si vous le souhaitez, en ajoutant une ou plusieurs de ces valeurs à l’attribut:
le bac à sable L'attribut iframe est pris en charge par tous les navigateurs modernes, à l'exception d'Opera Mini..
Alors c'est tout. J'espère que vous avez appris de nouvelles techniques que vous pourrez utiliser dans vos projets futurs pour protéger vos applications. Grâce à HTML5, nous pouvons maintenant faire des choses incroyables avec nos sites Web, mais nous devons penser à la sécurité dès la première ligne de code si nous voulons qu'ils soient résistants aux attaques..
