Grace à HTML5, de plus en plus les logique d’applications sont transférées du côté serveur au coté client. Cela nécessite des développeurs de se concentrer davantage sur la sécurité du front-end. Dans cet article je vais vous montrer comment faire des applications plus sécurisé. Je vais me concentrer sur les techniques que vous pourrez ne pas avoir entendu parler, au lieu de simplement vous dire que vous avez pour échapper à des données HTML entrés par les utilisateurs.
HTTP: n’y pensez même pas
Bien sûr,vous ne voudriez pas publier votre contenu sur du brut TCP. Ce que je veux dire, c’est que si vous si voulez que vos utilisateurs soient en sécurité lors de l’utilisation de votre site Web, vous devez utiliser le protocole SSL (HTTPS). Et pas seulement pour les pages de connexion, ou des informations précieuses mais pour l’ensemble de votre contenu. Sinon, lorsque quelqu’un accède à votre site à partir d’un réseau public, ce qu’ils voient peut être malformé par un pirate à l’intérieur de ce réseau en utilisant par exemple du DNS Spoofing, C’est ce qu’on appelle man-in-the-middle attack:
Lorsque vous utilisez SSL, toutes les données seront cryptées avant d’être envoyées, même si l’attaquant les obtient, il ne serait pas en mesure de modifier ou de le capturer.
Il y’a bien sur des techniques pour évader le SSL mais c’est de loin l’étape la plus importante dans la sécurisation de votre application.
Strict Transport Security:
Cette en-tête HTTP peut être utile si vous voulez servir votre contenu en utilisant uniquement SSL. Quand il est émis par le serveur (ou un tag meta, mais qui permettra au moins une demande pour être HTTP), pas de trafic non sécurisé viendra à partir du navigateur a votre serveur. Il est utilisé comme ceci:
Strict-Transport-Security: max-age = 3600; includeSubDomains
La partie includeSubDomains est facultatif, elle vous permet de déclarer que vous souhaitez également que tous les sous-domaines soient accessibles en utilisant le protocole HTTPS. L’option max-age définit combien de temps (en secondes) les pages doivent être servis en utilisant SSL. Malheureusement, seul Firefox, Chrome et Opera soutiennent Strict Transport Security, IE ?? et ben non pas encore…
Secure and HttpOnly:
Une autre façon d’améliorer la sécurité sur les protocoles HTTP et HTTPS sont ces deux attributs de cookie: « Secure » et « HTTPOnly« . Le premier permet un cookie doit être envoyé uniquement sur connexion SLL. Le second peut sembler comme l’exact opposé, mais il n’est pas. C’est en effet dire au navigateur que le cookie ne peut être accessible que via HTTP (S) protocole, de sorte qu’il ne peut pas être volé en utilisant, par exemple, document.cookie de JavaScript.
Content Security Policy pour rendre XSS moins dangereux:
Si vous pensez que votre filtre XSS s’arrête toutes les attaques possibles XSS vérifier combien de façons il ya à effectuer ces attaques et pensez à nouveau. Bien sûr, la sécurisation de votre application pour arrêter tous ceux-ci peut être un problème et peut ralentir, mais il ya une autre solution.
C’est ce qu’on appelle Content Security Policy. ça vous permet de définir l’origine de toutes les scripts, images, etc sur votre site. Il bloque également tous les scripts « inline » et les styles, de sorte que même si quelqu’un peut injecter une balise <script> dans un commentaire ou message, le code ne serait pas exécuté. Le CSP est un en-tête HTTP (qui peut également être définie à l’aide de la balise HTML <meta>), qui ressemble à ceci:
Content-Security-Policy: policy
Ou Policy est un ensemble de directives CSP. Voici les options possibles:
- script-src :sources de code JavaScript ensembles acceptables -
- style-src: définit origines acceptables de styles CSS
- connect-src : spécifie les serveurs ou le navigateur peut se connecter à l’aide de XHR, WebSockets et EventSource
- font-src : listes sources autorisées de polices
- frame-src – définit ce origines devraient être autorisés dans les iframes
- img-src : sources de séries d’images autorisés -
- média-src – Listes origines qui peuvent servir de fichiers audio et vidéo
- objet-src – même que ci-dessus mais pour Flash et autres plugins
Si une directive n’est pas définie, le navigateur suppose que toutes les origines sont autorisés. Ceci peut être changé en définissant l’option par default-src. Qu’est-ce que vous définissez, il sera appliqué à toutes les directives non définies. Il ya aussi une option de sandbox, ce qui rend la charge de page Web comme une iframe avec l’attribut sandbox. Un exemple d’utilisation de l’en-tête de CSP devrait ressembler à ceci:
Content-Security-Policy: default-src: 'self'; script-src: <a href="https://apis.google.com%3B/">https://apis.google.com;</a>
Il permet à tous les atouts d’être chargé uniquement de l’origine de la demande (l’attribut ‘self’) et vous permet de charger des scripts à partir du sereveur API Google aussi. Il ya beaucoup de flexibilité lors de la définition CSP, et lorsqu’il est utilisé correctement, il permettra d’améliorer grandement la sécurité de votre page web.
inconvénients
Ce qu’il faut retenir lors de l’utilisation du CSP est que, par défaut, tous les JavaScript en ligne ne sera pas exécuté. Cela comprend également:
les Listener d’événements en ligne: comme <body onload= »main(); »>
toutes les URL JavaScript: comme <a href= »javascript:doTheClick() »>
C’est parce que le navigateur ne peut pas distinguer votre code en ligne de celui du hacker. Vous aurez à les remplacer en ajoutant des écouteurs d’événement avec addEventListener ou autre. Ce n’est pas une mauvaise chose en fin de compte, car elle vous oblige à séparer la logique de votre application de la représentation graphique que vous devriez faire de toute façon. CSP également (par défaut) bloque tout eval (code), y compris les chaînes de setInterval / setTimeout et code comme:
new fonction (‘return false « );
Disponibilité
CSP est disponible dans la plupart des navigateurs modernes: Firefox, Chrome et Opera (mobile aussi) utiliser l’en-tête CSP standard. Safari (iOS trop) et Chrome pour Android utiliser l’en-tête X-webkit-CSP. IE10 (avec le soutien limité seulement à la directive sandbox) utilise X-Content-Security-policy. Ainsi, grâce à Internet Explorer, vous ne pouvez pas juste utiliser uniquement CSP (sauf si vous utilisez quelque chose comme Google Chrome Frame), mais vous pouvez toujours l’utiliser pour améliorer la sécurité sur les vrais navigateurs et à préparer votre application pour l’avenir.
Sandbox des iframe potentiellement nuisibles
Si vous utilisez les iframes pour charger le contenu de sites externes, vous pouvez les sécuriser. Cela peut être fait en utilisant l’attribut sandbox de iframe. Une 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, montrent des pop-ups ou soumettre des formulaires. La frame sera également avoir une origine unique, de sorte qu’il ne peut pas utiliser localStorage ou tout ce qui touche à la same-origin policy. Vous pouvez bien sûr permettre à certains d’entre eux, si vous voulez, en ajoutant un ou plusieurs de ces valeurs dans l’attribut:
- allow-same-origin : le cadre aura la même origine que le site, à la place de l’unique
- allow-scripts : le frame a la permission d’executer des scripts
- allow-forms : le frame peut envoyer des formulaires
- allow-pointer-lock : le frame peut blocker le pointeur
- allow-popups : le frame peut afficher des pop-up
- allow-top-navigation : le frame peut naviguer dans la fenêtre
Cet article Découvrez les meilleures pratiques de sécurité web coté client est apparu en premier sur kawageek.