Bonjour à tous ! Dans cette troisième vidéo, je vais vous présenter certaines contremesures existantes pour vous protéger des vulnérabilités XSS. Ces contremesures concernent plus particulièrement des XSS non permanentes et permanentes. Je vous rappelle que les XSS sont des vulnérabilités pouvant infecter les serveurs web ou les applications web qui ne filtrent pas les données dynamiques lors de la génération d'une page web, ou qui ne les filtre pas avant stockage côté serveur. Le résultat consiste en une exécution automatique d'un code javascript, par exemple, au moment du chargement et de l'exécution de la page par un navigateur web. La règle d'or est qu'il ne faut jamais faire confiance à un utilisateur lorsque nous lui laissons la possibilité de saisir des données. Que cela soit dans un champ de commentaires d'image, dans un champ de recherche ou encore dans un champ de commentaires sur un forum. De plus, il ne suffit pas de vérifier les données saisies avant stockage, car dans le cas d'une vulnérabilité XSS non permanente, cela n'aurait aucun effet. Il faut aussi valider les données avant leur utilisation côté client. [AUDIO_VIDE] La meilleure protection est de désactiver l'exécution de langage de scripts. Cette désactivation est possible, par exemple avec le javascript à l'aide d'add-ons qui sont installés dans les navigateurs, comme avec Firefox. Comme exemple d'add-ons, nous pouvons citer « no script ». Cependant, l'accès au site devient plus difficile, car un grand nombre de scripts JavaScript s'exécutent au chargement de page dans le navigateur. La plupart des sites internet se charge donc mal si on bloque le JavaScript. Aussi, certains navigateurs ont des détecteurs permettant de prévenir l'injection de code par XSS, mais il faut bien noter que ceux-ci sont désactivables par les utilisateurs du site. Il ne faut donc pas se fier à ce type de sécurité. Encore une fois, ne faites confiance à personne. Dans ce cas, comment pouvons-nous faire ? Voyons ensemble quelques règles fournies par l'OWASP, comme par exemple ne jamais utiliser des données non fiables dans un document HTML, encoder les données injectées dans les éléments de contenu, encoder les données non fiables dans les valeurs des attributs, encoder le JavaScript avant de l'utiliser s'il est généré de manière dynamique. La première règle est de ne jamais utiliser de données non fiables dans un document HTML, à l'exception de certains endroits que nous verrons plus loin. Les endroits où il ne faut jamais mettre de données non fiables sont les suivants : directement dans un script, donc c'est-à -dire entre les balises script ; dans un commentaire HTML, dans le nom d'un attribut, par exemple, dans le nom d'un attribut d'une balise <div></div>, dans le tag d'un nom, dans le CSS aussi dans les balises <style></style>. Ensuite, dans les éléments de contenu, il faut encoder les données injectées, par exemple dans les balises <div></div>, dans les balises <body></body>. dans les balises <p></p> avec le codage le codage HTML. Le codage HTML est par exemple le suivant : & qui se transforme en & ; ; le signe < qui devient < ; ; le signe > qui devient > ; . Cette liste n'est pas exhaustive. Cela fonctionne aussi pour les données non fiables utilisées dans les attributs à condition d'utiliser des codes simples dans vos attributs. Cependant, cela ne protège que pour l'injection de données dans du HTML. Cela ne fonctionne pas pour des utilisations de données non fiables pour des balises <script></script>, dans des événements comme « onmouseover », dans des CSS, ou encore dans des URL. Deuxièmement, il faut encoder des données non fiables utilisées dans les valeurs des attributs, comme les attributs « with name value ». Par exemple, dans la balise <div></div>, l'attribut est égal à une suite de caractères qui est injectée, cette suite de caractères doit être encodée avant son injection. Pareil pour la balise <div></div> avec un attribut entre cotes. Il est recommandé d'encoder tous les caractères avec une valeur ASCII inférieure à 256 sous la forme &#xHH ou HH représente la valeur du caractère à l'exception des caractères alphanumériques qui peuvent être conservés sous leur forme usuelle. Par exemple, le caractère < s'écrit < en hexadécimal. L'encodage permet de faire en sorte que les caractères tels que <, >, etc. ne soit pas interprétés. Nous verrons un peu plus loin comment l'encodage peut être réalisé. Troisièmement, vous devez encoder le JavaScript avant de l'utiliser s'il est généré de manière dynamique, que cela soit dans des blocs de code ou dans des événements. La seule manière d'insérer des données, est de la faire dans une valeur de donnée codée, c'est-à -dire entourée de code. Par exemple, le script suivant : <script> alert(), et entre parenthèses on va mettre des cotes et à l'intérieur de ces cotes les données encodées qui sont non fiables avant leur encodage. Aussi, dans une balise <div></div>, on peut utiliser l'attribut « onmouseover » pour gérer des événements. L'insertion de données non fiables dans l'attribut «onmouseover » doit être encodée pour être fiabilisée. Il est recommandé d'encoder tous les caractères avec une valeur ASCII inférieure à 256, comme pour l'utilisation de données non fiables dans les valeurs des attributs. À noter qu'il existe des fonctions JavaScript dans lesquelles il n'est pas possible d'utiliser de manière sûre des données non fiables, par exemple la fonction setInterval de JavaScript. Quatrièmement, il est impératif de contrôler les données passées dans une URL avec la méthode Get. En effet, un site internet utilisant une méthode Get pour le passage d'informations aura une adresse de la forme Monsite.fr?attribut=uneDonnee. La valeur uneDonnee du paramètre attribut peut être modifiée par l'attaquant voulant injecter du code tel que du JavaScript. Cette valeur ne doit jamais être utilisée telle quelle. Il faut encore une fois encoder en ASCII tous les caractères ayant une valeur inférieure à 256, sauf les caractères alphanumériques. Depuis tout à l'heure, nous parlons d'encodage des caractères comme moyen de protection, mais comment nous y prenons-nous. L'encodage est utilisé pour que le navigateur n'interprète pas certains caractères tels que le signe < ou >. Il est préférable d'utiliser des librairies d'encodage sécurisées pour faire cet encodage. Écrire soi-même des encodeurs est quelque chose qui n'est pas très compliqué, mais il existe des pièges. Vous pouvez par exemple utiliser la librairie OWASP Java Encoder Project du projet OWASP, qui offre une librairie d'encodage pour Java, ou encore vous pouvez utiliser the OWASP Enterprise Security API, qui est gratuite et open source, et qui aide le développement sécurisé d'applications web. Pour finir sur l'encodage des caractères, PHP fournit aussi des méthodes. Il s'agit des méthodes htmlentities et htmlspecialchars. Nous terminerons ces règles avec le drapeau HTTPOnly concernant les cookies. Ce drapeau permet d'interdire à JavaScript de récupérer les cookies, notamment les cookies de session, ou tout autre cookie ne devant pas être accessible par JavaScript. Par exemple, le JavaScript document.cookie ne fonctionnera pas pour récupérer un cookie. Reprenons notre exemple : lorsque nous avons inséré dans le champ de recherche le JavaScript suivant, une pop-up s'était affichée avec notre code. Je vous laisse le temps de regarder l'exemple. Pour empêcher cela, nous avons modifié notre code. Le code vulnérable était pour rappel le suivant : Je vous laisse encore un peu de temps pour le regarder. Nous l'avons modifié pour utiliser la fonction PHP htmlentities comme ceci : La fonction htmlentities est équivalente à la fonction htmlspecialchars, à l'exception que si un caractère a un équivalent en HTML, alors il sera converti. Le résultat de cette utilisation est que les caractères inférieurs et supérieurs ont été encodés en HTML, ce qui donne la chaîne de caractères suivante : Par conséquent, le JavaScript n'est plus interprété par le navigateur comme vous pouvez le voir sur la capture d'écran suivante : [AUDIO_VIDE] Pour conclure, nous venons de voir ensemble certaines règles qu'il convient de suivre pour sécuriser son site internet contre les vulnérabilités XSS. Elles sont d'ailleurs préconisées par l'OWASP. Il existe d'autres règles à respecter pour améliorer la sécurisation. Souvenez-vous qu'il ne faut jamais faire confiance à un utilisateur, vous devez contrôler ce que saisit l'utilisateur et ce qui est affiché dynamiquement sur une page web. Pour finir, quelques mots sur les API. L'informatique évoluant sans cesse, les attaques évoluent mais la défense s'améliore également. Il convient de suivre les évolutions. Il faut notamment suivre les informations sur la dépréciation des API qui indiquent qu'il ne faut plus utiliser telle ou telle version, et remplacer celle-ci par la nouvelle [INCOMPRÉHENSIBLE].
