Les codeurs à la conquête de la sécurité : Partager et apprendre - Cross-Site Scripting (XSS)
Les scripts intersites (XSS) sont un fléau pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, ils constituent toujours l'une des menaces les plus courantes au niveau du code. Cette catégorie de vulnérabilité logicielle nous tourmente depuis bien trop longtemps, et une alerte récente de la CISA - dans le cadre de son mouvement "Secure-by-Design" - cherche à la contrecarrer une fois pour toutes. La CISA s'est donné pour mission d'éliminer les classes de vulnérabilités à l'échelle mondiale, et ce coup de projecteur sur la sécurité pilotée par les développeurs peut vraiment faire bouger les choses, mais il faudra pour cela que les entreprises intelligentes s'engagent à mettre leurs développeurs sur la voie de la réussite en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs web sont peut-être notre porte d'entrée vers toutes ces choses géniales en ligne, mais malheureusement, il n'y a pas que des bonnes nouvelles. Le comportement inhérent des navigateurs web peut être un catalyseur de vulnérabilités en matière de sécurité. Les navigateurs ont commencé par faire confiance aux balises qu'ils voyaient et les exécutaient sans poser de questions. Tout va bien jusqu'à ce que cette fonctionnalité soit exploitée à des fins peu recommandables... et naturellement, les attaquants ont fini par trouver des moyens d'exploiter cette tendance à des fins malveillantes.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, s'emparer de comptes et défigurer des sites web ; il s'agit d'une vulnérabilité qui peut devenir très moche, très rapidement.
Voyons comment fonctionne le XSS, quels sont les dommages qu'il peut causer et comment s'en prémunir :
Comment fonctionne un XSS ?
Un XSS se produit lorsqu'une entrée non fiable (souvent des données) est affichée sur une page, mais interprétée à tort comme un code exécutable. Un attaquant peut placer un code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée, qui - lorsqu'il est renvoyé au navigateur - est alors exécuté au lieu d'être affiché comme des données.
Comme indiqué ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de faire la distinction entre les données et le code exécutable. Le modèle de fonctionnement du web est le suivant :
- L'utilisateur visite une page web
- La page indique au navigateur les fichiers à charger et à exécuter
- Le navigateur exécute ce qui se trouve sur la page, sans poser de questions.
Cette fonctionnalité est à l'origine de certaines des expériences interactives les plus impressionnantes dont nous bénéficions sur le web. Le revers de la médaille est qu'elle a également donné lieu à des exploits et à des vulnérabilités coûteux.
Lorsque les attaquants ajoutent leur script malveillant à un site vulnérable, celui-ci est exécuté sans poser de questions. Il n'y a pas d'enquête plus approfondie, ni de mesures de détection en place.
Il existe trois types de XSS :
- XSS stocké
- XSS réfléchi
- DOM XSS
On parle de XSS stocké lorsqu'un attaquant peut stocker de manière persistante le script malveillant dans un champ de données de l'application (par exemple, dans un champ qui stocke le numéro de téléphone mobile de l'utilisateur). Ce script est ensuite envoyé au navigateur de l'utilisateur chaque fois que ce champ de données est affiché dans l'application.
Ce type d'attaque est souvent observé sur les sites de forums ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et bam - chaque utilisateur qui consulte ce commentaire exécute le script à son insu.
LeXSS réfléchi se produit lorsque l'entrée de l'utilisateur est renvoyée telle quelle au navigateur de l'utilisateur. Un exemple est une boîte de recherche qui affiche "Vous avez cherché ..." à l'utilisateur pendant qu'il récupère les résultats de la recherche.
Imaginez maintenant que la recherche fonctionne en plaçant le terme recherché dans l'URL en tant que paramètres de requête. Un attaquant malveillant pourrait envoyer à la victime un lien contenant le script malveillant intégré dans ces mêmes paramètres et, à vrai dire, la plupart des utilisateurs du web le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site d'hameçonnage où elle saisit involontairement son mot de passe pour le site. Elle est loin de se douter qu'un pirate vient de lui voler la clé de son compte.
DOM XSS est une variante relativement récente de cette vulnérabilité. Elle tire parti des structures de template complexes que l'on trouve dans de nombreux frameworks d'interface utilisateur tels qu'Angular et React.
Ces templates permettent d'obtenir un contenu dynamique et des applications d'interface utilisateur riches. S'ils sont mal utilisés, ils peuvent être utilisés pour exécuter des attaques XSS.
Voilà, vous l'avez. Vous avez une vue d'ensemble de la portée des XSS. Voyons maintenant comment il peut être utilisé de manière destructive.
Pourquoi les XSS sont-ils si dangereux ?
Les attaques XSS peuvent être utilisées pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En fait, tout ce que JavaScript peut faire, les attaques XSS en sont également capables.
Voici trois exemples d'attaques XSS :
- En 2015, les utilisateurs de Yahoo ont vu leurs cookies de session dérobés au moyen d'un XSS.
- Le ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il reste le logiciel malveillant qui s'est propagé le plus rapidement de tous les temps, affectant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'insertion de scripts malveillants dans les descriptions de produits. Cela a conduit à des attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont faussement simples et très sérieuses. Elles peuvent conduire au vol de sessions, d'identifiants d'utilisateurs ou de données sensibles. L'atteinte à la réputation et la baisse des revenus sont les principaux écueils de ces attaques. Le simple fait de défigurer un site web peut avoir des conséquences fâcheuses pour une entreprise.
Cependant, un guerrier de la sécurité avisé comme vous peut déjouer les attaques XSS. La solution n'est pas compliquée et l'industrie a parcouru un long, très long chemin depuis que XSS est devenu un exploit couramment utilisé.
Vous pouvez vaincre les XSS.
La clé pour vaincre les XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre entrée utilisateur sera restituée au client et l'endroit où elle sera restituée. Dans le code HTML ou dans un extrait de JavaScript.
Si la saisie de l'utilisateur n'a pas besoin d'être renvoyée au navigateur, tant mieux. Mais si c'est le cas, elle doit souvent être codée en HTML. Le codage HTML de la sortie indiquera au navigateur de rendre le contenu tel quel et de ne pas l'exécuter.
La validation des entrées est également importante. Cependant, la validation et la liste blanche ne sont pas des solutions infaillibles. Le codage va un peu plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas pris en compte par les stratégies de validation et de liste blanche sera encodé.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angular, ASP.NET MVC et React.js sont des frameworks dans lesquels l'encodage HTML par défaut est utilisé. Vous devez spécifiquement indiquer à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks, (i.e. Django et Spring) ont des bibliothèques standard pour la prévention XSS que vous pouvez facilement incorporer dans votre code.
Le plus grand défi est d'apprendre à analyser toutes les façons dont l'entrée utilisateur peut pénétrer dans un système afin que vous puissiez rester à l'affût de ces entrées. Les paramètres de requête peuvent être à l'origine d'attaques, tout comme les paramètres d'affichage. Suivez le flux de données à travers votre application et ne faites confiance à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Arrêtez chaque donnée, inspectez-la et ne l'autorisez pas à entrer si elle semble malveillante. Encodez ensuite les données lors du rendu pour vous assurer que les éléments malveillants qui ont été manqués ne causeront pas de problèmes.
Mettez en œuvre ces stratégies et vos utilisateurs seront à l'abri d'une attaque par XSS. Consultez l'aide-mémoire de l'OWASP pour obtenir d'autres conseils afin de garder vos données sous contrôle.
Déjouez les XSS et améliorez vos compétences en matière de sécurité.
Le XSS occupe la septième place dans le Top 10 2017 de l'OWASP des risques de sécurité sur le web. Il existe depuis un certain temps, mais il peut toujours apparaître et causer des problèmes avec votre application si vous ne faites pas attention.
La formation est très importante pour les développeurs, car elle leur permet d'acquérir un état d'esprit axé sur la sécurité lorsqu'ils créent du code. Et cette formation est toujours plus efficace lorsqu'elle simule des applications réelles, dans les langages que les développeurs utilisent activement. Dans cette optique, pourquoi ne pas consulter nos ressources pédagogiques pour en savoir plus sur les XSS ? Ensuite, vous pourrez commencer la formation et la pratique qui vous mèneront à la maîtrise.
Vous pensez être prêt à trouver et à corriger les vulnérabilités XSS dès maintenant ? Lancez-vous un défi sur la plateforme Secure Code Warrior .
Les scripts intersites (XSS) profitent de la confiance des navigateurs et de l'ignorance des utilisateurs pour voler des données, s'emparer de comptes et défigurer des sites web ; il s'agit d'une vulnérabilité qui peut rapidement devenir très gênante. Voyons comment fonctionne le XSS, quels sont les dommages qu'il peut causer et comment s'en prémunir.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstration
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Les scripts intersites (XSS) sont un fléau pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, ils constituent toujours l'une des menaces les plus courantes au niveau du code. Cette catégorie de vulnérabilité logicielle nous tourmente depuis bien trop longtemps, et une alerte récente de la CISA - dans le cadre de son mouvement "Secure-by-Design" - cherche à la contrecarrer une fois pour toutes. La CISA s'est donné pour mission d'éliminer les classes de vulnérabilités à l'échelle mondiale, et ce coup de projecteur sur la sécurité pilotée par les développeurs peut vraiment faire bouger les choses, mais il faudra pour cela que les entreprises intelligentes s'engagent à mettre leurs développeurs sur la voie de la réussite en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs web sont peut-être notre porte d'entrée vers toutes ces choses géniales en ligne, mais malheureusement, il n'y a pas que des bonnes nouvelles. Le comportement inhérent des navigateurs web peut être un catalyseur de vulnérabilités en matière de sécurité. Les navigateurs ont commencé par faire confiance aux balises qu'ils voyaient et les exécutaient sans poser de questions. Tout va bien jusqu'à ce que cette fonctionnalité soit exploitée à des fins peu recommandables... et naturellement, les attaquants ont fini par trouver des moyens d'exploiter cette tendance à des fins malveillantes.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, s'emparer de comptes et défigurer des sites web ; il s'agit d'une vulnérabilité qui peut devenir très moche, très rapidement.
Voyons comment fonctionne le XSS, quels sont les dommages qu'il peut causer et comment s'en prémunir :
Comment fonctionne un XSS ?
Un XSS se produit lorsqu'une entrée non fiable (souvent des données) est affichée sur une page, mais interprétée à tort comme un code exécutable. Un attaquant peut placer un code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée, qui - lorsqu'il est renvoyé au navigateur - est alors exécuté au lieu d'être affiché comme des données.
Comme indiqué ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de faire la distinction entre les données et le code exécutable. Le modèle de fonctionnement du web est le suivant :
- L'utilisateur visite une page web
- La page indique au navigateur les fichiers à charger et à exécuter
- Le navigateur exécute ce qui se trouve sur la page, sans poser de questions.
Cette fonctionnalité est à l'origine de certaines des expériences interactives les plus impressionnantes dont nous bénéficions sur le web. Le revers de la médaille est qu'elle a également donné lieu à des exploits et à des vulnérabilités coûteux.
Lorsque les attaquants ajoutent leur script malveillant à un site vulnérable, celui-ci est exécuté sans poser de questions. Il n'y a pas d'enquête plus approfondie, ni de mesures de détection en place.
Il existe trois types de XSS :
- XSS stocké
- XSS réfléchi
- DOM XSS
On parle de XSS stocké lorsqu'un attaquant peut stocker de manière persistante le script malveillant dans un champ de données de l'application (par exemple, dans un champ qui stocke le numéro de téléphone mobile de l'utilisateur). Ce script est ensuite envoyé au navigateur de l'utilisateur chaque fois que ce champ de données est affiché dans l'application.
Ce type d'attaque est souvent observé sur les sites de forums ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et bam - chaque utilisateur qui consulte ce commentaire exécute le script à son insu.
LeXSS réfléchi se produit lorsque l'entrée de l'utilisateur est renvoyée telle quelle au navigateur de l'utilisateur. Un exemple est une boîte de recherche qui affiche "Vous avez cherché ..." à l'utilisateur pendant qu'il récupère les résultats de la recherche.
Imaginez maintenant que la recherche fonctionne en plaçant le terme recherché dans l'URL en tant que paramètres de requête. Un attaquant malveillant pourrait envoyer à la victime un lien contenant le script malveillant intégré dans ces mêmes paramètres et, à vrai dire, la plupart des utilisateurs du web le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site d'hameçonnage où elle saisit involontairement son mot de passe pour le site. Elle est loin de se douter qu'un pirate vient de lui voler la clé de son compte.
DOM XSS est une variante relativement récente de cette vulnérabilité. Elle tire parti des structures de template complexes que l'on trouve dans de nombreux frameworks d'interface utilisateur tels qu'Angular et React.
Ces templates permettent d'obtenir un contenu dynamique et des applications d'interface utilisateur riches. S'ils sont mal utilisés, ils peuvent être utilisés pour exécuter des attaques XSS.
Voilà, vous l'avez. Vous avez une vue d'ensemble de la portée des XSS. Voyons maintenant comment il peut être utilisé de manière destructive.
Pourquoi les XSS sont-ils si dangereux ?
Les attaques XSS peuvent être utilisées pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En fait, tout ce que JavaScript peut faire, les attaques XSS en sont également capables.
Voici trois exemples d'attaques XSS :
- En 2015, les utilisateurs de Yahoo ont vu leurs cookies de session dérobés au moyen d'un XSS.
- Le ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il reste le logiciel malveillant qui s'est propagé le plus rapidement de tous les temps, affectant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'insertion de scripts malveillants dans les descriptions de produits. Cela a conduit à des attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont faussement simples et très sérieuses. Elles peuvent conduire au vol de sessions, d'identifiants d'utilisateurs ou de données sensibles. L'atteinte à la réputation et la baisse des revenus sont les principaux écueils de ces attaques. Le simple fait de défigurer un site web peut avoir des conséquences fâcheuses pour une entreprise.
Cependant, un guerrier de la sécurité avisé comme vous peut déjouer les attaques XSS. La solution n'est pas compliquée et l'industrie a parcouru un long, très long chemin depuis que XSS est devenu un exploit couramment utilisé.
Vous pouvez vaincre les XSS.
La clé pour vaincre les XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre entrée utilisateur sera restituée au client et l'endroit où elle sera restituée. Dans le code HTML ou dans un extrait de JavaScript.
Si la saisie de l'utilisateur n'a pas besoin d'être renvoyée au navigateur, tant mieux. Mais si c'est le cas, elle doit souvent être codée en HTML. Le codage HTML de la sortie indiquera au navigateur de rendre le contenu tel quel et de ne pas l'exécuter.
La validation des entrées est également importante. Cependant, la validation et la liste blanche ne sont pas des solutions infaillibles. Le codage va un peu plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas pris en compte par les stratégies de validation et de liste blanche sera encodé.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angular, ASP.NET MVC et React.js sont des frameworks dans lesquels l'encodage HTML par défaut est utilisé. Vous devez spécifiquement indiquer à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks, (i.e. Django et Spring) ont des bibliothèques standard pour la prévention XSS que vous pouvez facilement incorporer dans votre code.
Le plus grand défi est d'apprendre à analyser toutes les façons dont l'entrée utilisateur peut pénétrer dans un système afin que vous puissiez rester à l'affût de ces entrées. Les paramètres de requête peuvent être à l'origine d'attaques, tout comme les paramètres d'affichage. Suivez le flux de données à travers votre application et ne faites confiance à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Arrêtez chaque donnée, inspectez-la et ne l'autorisez pas à entrer si elle semble malveillante. Encodez ensuite les données lors du rendu pour vous assurer que les éléments malveillants qui ont été manqués ne causeront pas de problèmes.
Mettez en œuvre ces stratégies et vos utilisateurs seront à l'abri d'une attaque par XSS. Consultez l'aide-mémoire de l'OWASP pour obtenir d'autres conseils afin de garder vos données sous contrôle.
Déjouez les XSS et améliorez vos compétences en matière de sécurité.
Le XSS occupe la septième place dans le Top 10 2017 de l'OWASP des risques de sécurité sur le web. Il existe depuis un certain temps, mais il peut toujours apparaître et causer des problèmes avec votre application si vous ne faites pas attention.
La formation est très importante pour les développeurs, car elle leur permet d'acquérir un état d'esprit axé sur la sécurité lorsqu'ils créent du code. Et cette formation est toujours plus efficace lorsqu'elle simule des applications réelles, dans les langages que les développeurs utilisent activement. Dans cette optique, pourquoi ne pas consulter nos ressources pédagogiques pour en savoir plus sur les XSS ? Ensuite, vous pourrez commencer la formation et la pratique qui vous mèneront à la maîtrise.
Vous pensez être prêt à trouver et à corriger les vulnérabilités XSS dès maintenant ? Lancez-vous un défi sur la plateforme Secure Code Warrior .
Les scripts intersites (XSS) sont un fléau pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, ils constituent toujours l'une des menaces les plus courantes au niveau du code. Cette catégorie de vulnérabilité logicielle nous tourmente depuis bien trop longtemps, et une alerte récente de la CISA - dans le cadre de son mouvement "Secure-by-Design" - cherche à la contrecarrer une fois pour toutes. La CISA s'est donné pour mission d'éliminer les classes de vulnérabilités à l'échelle mondiale, et ce coup de projecteur sur la sécurité pilotée par les développeurs peut vraiment faire bouger les choses, mais il faudra pour cela que les entreprises intelligentes s'engagent à mettre leurs développeurs sur la voie de la réussite en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs web sont peut-être notre porte d'entrée vers toutes ces choses géniales en ligne, mais malheureusement, il n'y a pas que des bonnes nouvelles. Le comportement inhérent des navigateurs web peut être un catalyseur de vulnérabilités en matière de sécurité. Les navigateurs ont commencé par faire confiance aux balises qu'ils voyaient et les exécutaient sans poser de questions. Tout va bien jusqu'à ce que cette fonctionnalité soit exploitée à des fins peu recommandables... et naturellement, les attaquants ont fini par trouver des moyens d'exploiter cette tendance à des fins malveillantes.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, s'emparer de comptes et défigurer des sites web ; il s'agit d'une vulnérabilité qui peut devenir très moche, très rapidement.
Voyons comment fonctionne le XSS, quels sont les dommages qu'il peut causer et comment s'en prémunir :
Comment fonctionne un XSS ?
Un XSS se produit lorsqu'une entrée non fiable (souvent des données) est affichée sur une page, mais interprétée à tort comme un code exécutable. Un attaquant peut placer un code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée, qui - lorsqu'il est renvoyé au navigateur - est alors exécuté au lieu d'être affiché comme des données.
Comme indiqué ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de faire la distinction entre les données et le code exécutable. Le modèle de fonctionnement du web est le suivant :
- L'utilisateur visite une page web
- La page indique au navigateur les fichiers à charger et à exécuter
- Le navigateur exécute ce qui se trouve sur la page, sans poser de questions.
Cette fonctionnalité est à l'origine de certaines des expériences interactives les plus impressionnantes dont nous bénéficions sur le web. Le revers de la médaille est qu'elle a également donné lieu à des exploits et à des vulnérabilités coûteux.
Lorsque les attaquants ajoutent leur script malveillant à un site vulnérable, celui-ci est exécuté sans poser de questions. Il n'y a pas d'enquête plus approfondie, ni de mesures de détection en place.
Il existe trois types de XSS :
- XSS stocké
- XSS réfléchi
- DOM XSS
On parle de XSS stocké lorsqu'un attaquant peut stocker de manière persistante le script malveillant dans un champ de données de l'application (par exemple, dans un champ qui stocke le numéro de téléphone mobile de l'utilisateur). Ce script est ensuite envoyé au navigateur de l'utilisateur chaque fois que ce champ de données est affiché dans l'application.
Ce type d'attaque est souvent observé sur les sites de forums ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et bam - chaque utilisateur qui consulte ce commentaire exécute le script à son insu.
LeXSS réfléchi se produit lorsque l'entrée de l'utilisateur est renvoyée telle quelle au navigateur de l'utilisateur. Un exemple est une boîte de recherche qui affiche "Vous avez cherché ..." à l'utilisateur pendant qu'il récupère les résultats de la recherche.
Imaginez maintenant que la recherche fonctionne en plaçant le terme recherché dans l'URL en tant que paramètres de requête. Un attaquant malveillant pourrait envoyer à la victime un lien contenant le script malveillant intégré dans ces mêmes paramètres et, à vrai dire, la plupart des utilisateurs du web le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site d'hameçonnage où elle saisit involontairement son mot de passe pour le site. Elle est loin de se douter qu'un pirate vient de lui voler la clé de son compte.
DOM XSS est une variante relativement récente de cette vulnérabilité. Elle tire parti des structures de template complexes que l'on trouve dans de nombreux frameworks d'interface utilisateur tels qu'Angular et React.
Ces templates permettent d'obtenir un contenu dynamique et des applications d'interface utilisateur riches. S'ils sont mal utilisés, ils peuvent être utilisés pour exécuter des attaques XSS.
Voilà, vous l'avez. Vous avez une vue d'ensemble de la portée des XSS. Voyons maintenant comment il peut être utilisé de manière destructive.
Pourquoi les XSS sont-ils si dangereux ?
Les attaques XSS peuvent être utilisées pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En fait, tout ce que JavaScript peut faire, les attaques XSS en sont également capables.
Voici trois exemples d'attaques XSS :
- En 2015, les utilisateurs de Yahoo ont vu leurs cookies de session dérobés au moyen d'un XSS.
- Le ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il reste le logiciel malveillant qui s'est propagé le plus rapidement de tous les temps, affectant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'insertion de scripts malveillants dans les descriptions de produits. Cela a conduit à des attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont faussement simples et très sérieuses. Elles peuvent conduire au vol de sessions, d'identifiants d'utilisateurs ou de données sensibles. L'atteinte à la réputation et la baisse des revenus sont les principaux écueils de ces attaques. Le simple fait de défigurer un site web peut avoir des conséquences fâcheuses pour une entreprise.
Cependant, un guerrier de la sécurité avisé comme vous peut déjouer les attaques XSS. La solution n'est pas compliquée et l'industrie a parcouru un long, très long chemin depuis que XSS est devenu un exploit couramment utilisé.
Vous pouvez vaincre les XSS.
La clé pour vaincre les XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre entrée utilisateur sera restituée au client et l'endroit où elle sera restituée. Dans le code HTML ou dans un extrait de JavaScript.
Si la saisie de l'utilisateur n'a pas besoin d'être renvoyée au navigateur, tant mieux. Mais si c'est le cas, elle doit souvent être codée en HTML. Le codage HTML de la sortie indiquera au navigateur de rendre le contenu tel quel et de ne pas l'exécuter.
La validation des entrées est également importante. Cependant, la validation et la liste blanche ne sont pas des solutions infaillibles. Le codage va un peu plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas pris en compte par les stratégies de validation et de liste blanche sera encodé.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angular, ASP.NET MVC et React.js sont des frameworks dans lesquels l'encodage HTML par défaut est utilisé. Vous devez spécifiquement indiquer à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks, (i.e. Django et Spring) ont des bibliothèques standard pour la prévention XSS que vous pouvez facilement incorporer dans votre code.
Le plus grand défi est d'apprendre à analyser toutes les façons dont l'entrée utilisateur peut pénétrer dans un système afin que vous puissiez rester à l'affût de ces entrées. Les paramètres de requête peuvent être à l'origine d'attaques, tout comme les paramètres d'affichage. Suivez le flux de données à travers votre application et ne faites confiance à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Arrêtez chaque donnée, inspectez-la et ne l'autorisez pas à entrer si elle semble malveillante. Encodez ensuite les données lors du rendu pour vous assurer que les éléments malveillants qui ont été manqués ne causeront pas de problèmes.
Mettez en œuvre ces stratégies et vos utilisateurs seront à l'abri d'une attaque par XSS. Consultez l'aide-mémoire de l'OWASP pour obtenir d'autres conseils afin de garder vos données sous contrôle.
Déjouez les XSS et améliorez vos compétences en matière de sécurité.
Le XSS occupe la septième place dans le Top 10 2017 de l'OWASP des risques de sécurité sur le web. Il existe depuis un certain temps, mais il peut toujours apparaître et causer des problèmes avec votre application si vous ne faites pas attention.
La formation est très importante pour les développeurs, car elle leur permet d'acquérir un état d'esprit axé sur la sécurité lorsqu'ils créent du code. Et cette formation est toujours plus efficace lorsqu'elle simule des applications réelles, dans les langages que les développeurs utilisent activement. Dans cette optique, pourquoi ne pas consulter nos ressources pédagogiques pour en savoir plus sur les XSS ? Ensuite, vous pourrez commencer la formation et la pratique qui vous mèneront à la maîtrise.
Vous pensez être prêt à trouver et à corriger les vulnérabilités XSS dès maintenant ? Lancez-vous un défi sur la plateforme Secure Code Warrior .
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstration
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Les scripts intersites (XSS) sont un fléau pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, ils constituent toujours l'une des menaces les plus courantes au niveau du code. Cette catégorie de vulnérabilité logicielle nous tourmente depuis bien trop longtemps, et une alerte récente de la CISA - dans le cadre de son mouvement "Secure-by-Design" - cherche à la contrecarrer une fois pour toutes. La CISA s'est donné pour mission d'éliminer les classes de vulnérabilités à l'échelle mondiale, et ce coup de projecteur sur la sécurité pilotée par les développeurs peut vraiment faire bouger les choses, mais il faudra pour cela que les entreprises intelligentes s'engagent à mettre leurs développeurs sur la voie de la réussite en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs web sont peut-être notre porte d'entrée vers toutes ces choses géniales en ligne, mais malheureusement, il n'y a pas que des bonnes nouvelles. Le comportement inhérent des navigateurs web peut être un catalyseur de vulnérabilités en matière de sécurité. Les navigateurs ont commencé par faire confiance aux balises qu'ils voyaient et les exécutaient sans poser de questions. Tout va bien jusqu'à ce que cette fonctionnalité soit exploitée à des fins peu recommandables... et naturellement, les attaquants ont fini par trouver des moyens d'exploiter cette tendance à des fins malveillantes.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, s'emparer de comptes et défigurer des sites web ; il s'agit d'une vulnérabilité qui peut devenir très moche, très rapidement.
Voyons comment fonctionne le XSS, quels sont les dommages qu'il peut causer et comment s'en prémunir :
Comment fonctionne un XSS ?
Un XSS se produit lorsqu'une entrée non fiable (souvent des données) est affichée sur une page, mais interprétée à tort comme un code exécutable. Un attaquant peut placer un code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée, qui - lorsqu'il est renvoyé au navigateur - est alors exécuté au lieu d'être affiché comme des données.
Comme indiqué ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de faire la distinction entre les données et le code exécutable. Le modèle de fonctionnement du web est le suivant :
- L'utilisateur visite une page web
- La page indique au navigateur les fichiers à charger et à exécuter
- Le navigateur exécute ce qui se trouve sur la page, sans poser de questions.
Cette fonctionnalité est à l'origine de certaines des expériences interactives les plus impressionnantes dont nous bénéficions sur le web. Le revers de la médaille est qu'elle a également donné lieu à des exploits et à des vulnérabilités coûteux.
Lorsque les attaquants ajoutent leur script malveillant à un site vulnérable, celui-ci est exécuté sans poser de questions. Il n'y a pas d'enquête plus approfondie, ni de mesures de détection en place.
Il existe trois types de XSS :
- XSS stocké
- XSS réfléchi
- DOM XSS
On parle de XSS stocké lorsqu'un attaquant peut stocker de manière persistante le script malveillant dans un champ de données de l'application (par exemple, dans un champ qui stocke le numéro de téléphone mobile de l'utilisateur). Ce script est ensuite envoyé au navigateur de l'utilisateur chaque fois que ce champ de données est affiché dans l'application.
Ce type d'attaque est souvent observé sur les sites de forums ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et bam - chaque utilisateur qui consulte ce commentaire exécute le script à son insu.
LeXSS réfléchi se produit lorsque l'entrée de l'utilisateur est renvoyée telle quelle au navigateur de l'utilisateur. Un exemple est une boîte de recherche qui affiche "Vous avez cherché ..." à l'utilisateur pendant qu'il récupère les résultats de la recherche.
Imaginez maintenant que la recherche fonctionne en plaçant le terme recherché dans l'URL en tant que paramètres de requête. Un attaquant malveillant pourrait envoyer à la victime un lien contenant le script malveillant intégré dans ces mêmes paramètres et, à vrai dire, la plupart des utilisateurs du web le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site d'hameçonnage où elle saisit involontairement son mot de passe pour le site. Elle est loin de se douter qu'un pirate vient de lui voler la clé de son compte.
DOM XSS est une variante relativement récente de cette vulnérabilité. Elle tire parti des structures de template complexes que l'on trouve dans de nombreux frameworks d'interface utilisateur tels qu'Angular et React.
Ces templates permettent d'obtenir un contenu dynamique et des applications d'interface utilisateur riches. S'ils sont mal utilisés, ils peuvent être utilisés pour exécuter des attaques XSS.
Voilà, vous l'avez. Vous avez une vue d'ensemble de la portée des XSS. Voyons maintenant comment il peut être utilisé de manière destructive.
Pourquoi les XSS sont-ils si dangereux ?
Les attaques XSS peuvent être utilisées pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En fait, tout ce que JavaScript peut faire, les attaques XSS en sont également capables.
Voici trois exemples d'attaques XSS :
- En 2015, les utilisateurs de Yahoo ont vu leurs cookies de session dérobés au moyen d'un XSS.
- Le ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il reste le logiciel malveillant qui s'est propagé le plus rapidement de tous les temps, affectant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'insertion de scripts malveillants dans les descriptions de produits. Cela a conduit à des attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont faussement simples et très sérieuses. Elles peuvent conduire au vol de sessions, d'identifiants d'utilisateurs ou de données sensibles. L'atteinte à la réputation et la baisse des revenus sont les principaux écueils de ces attaques. Le simple fait de défigurer un site web peut avoir des conséquences fâcheuses pour une entreprise.
Cependant, un guerrier de la sécurité avisé comme vous peut déjouer les attaques XSS. La solution n'est pas compliquée et l'industrie a parcouru un long, très long chemin depuis que XSS est devenu un exploit couramment utilisé.
Vous pouvez vaincre les XSS.
La clé pour vaincre les XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre entrée utilisateur sera restituée au client et l'endroit où elle sera restituée. Dans le code HTML ou dans un extrait de JavaScript.
Si la saisie de l'utilisateur n'a pas besoin d'être renvoyée au navigateur, tant mieux. Mais si c'est le cas, elle doit souvent être codée en HTML. Le codage HTML de la sortie indiquera au navigateur de rendre le contenu tel quel et de ne pas l'exécuter.
La validation des entrées est également importante. Cependant, la validation et la liste blanche ne sont pas des solutions infaillibles. Le codage va un peu plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas pris en compte par les stratégies de validation et de liste blanche sera encodé.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angular, ASP.NET MVC et React.js sont des frameworks dans lesquels l'encodage HTML par défaut est utilisé. Vous devez spécifiquement indiquer à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks, (i.e. Django et Spring) ont des bibliothèques standard pour la prévention XSS que vous pouvez facilement incorporer dans votre code.
Le plus grand défi est d'apprendre à analyser toutes les façons dont l'entrée utilisateur peut pénétrer dans un système afin que vous puissiez rester à l'affût de ces entrées. Les paramètres de requête peuvent être à l'origine d'attaques, tout comme les paramètres d'affichage. Suivez le flux de données à travers votre application et ne faites confiance à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Arrêtez chaque donnée, inspectez-la et ne l'autorisez pas à entrer si elle semble malveillante. Encodez ensuite les données lors du rendu pour vous assurer que les éléments malveillants qui ont été manqués ne causeront pas de problèmes.
Mettez en œuvre ces stratégies et vos utilisateurs seront à l'abri d'une attaque par XSS. Consultez l'aide-mémoire de l'OWASP pour obtenir d'autres conseils afin de garder vos données sous contrôle.
Déjouez les XSS et améliorez vos compétences en matière de sécurité.
Le XSS occupe la septième place dans le Top 10 2017 de l'OWASP des risques de sécurité sur le web. Il existe depuis un certain temps, mais il peut toujours apparaître et causer des problèmes avec votre application si vous ne faites pas attention.
La formation est très importante pour les développeurs, car elle leur permet d'acquérir un état d'esprit axé sur la sécurité lorsqu'ils créent du code. Et cette formation est toujours plus efficace lorsqu'elle simule des applications réelles, dans les langages que les développeurs utilisent activement. Dans cette optique, pourquoi ne pas consulter nos ressources pédagogiques pour en savoir plus sur les XSS ? Ensuite, vous pourrez commencer la formation et la pratique qui vous mèneront à la maîtrise.
Vous pensez être prêt à trouver et à corriger les vulnérabilités XSS dès maintenant ? Lancez-vous un défi sur la plateforme Secure Code Warrior .
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
La puissance d'OpenText Fortify + Secure Code Warrior
OpenText Fortify et Secure Code Warrior unissent leurs forces pour aider les entreprises à réduire les risques, à transformer les développeurs en champions de la sécurité et à renforcer la confiance des clients. Pour en savoir plus, cliquez ici.
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
Ressources pour vous aider à démarrer
10 prédictions clés : Secure Code Warrior sur l'influence de l'IA et de la conception sécurisée en 2025
Les organisations sont confrontées à des décisions difficiles sur l'utilisation de l'IA pour soutenir la productivité à long terme, la durabilité et le retour sur investissement de la sécurité. Au cours des dernières années, il nous est apparu clairement que l'IA ne remplacera jamais complètement le rôle du développeur. Des partenariats IA + développeurs aux pressions croissantes (et à la confusion) autour des attentes en matière de conception sécurisée, examinons de plus près ce à quoi nous pouvons nous attendre au cours de l'année prochaine.
OWASP Top 10 pour les applications LLM : Ce qui est nouveau, ce qui a changé et comment rester en sécurité
Gardez une longueur d'avance dans la sécurisation des applications LLM avec les dernières mises à jour du Top 10 de l'OWASP. Découvrez ce qui est nouveau, ce qui a changé et comment Secure Code Warrior vous fournit des ressources d'apprentissage actualisées pour atténuer les risques dans l'IA générative.
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
.png)
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
