Les codeurs conquièrent la sécurité : partagez et apprenez - Cross-Site Scripting (XSS)
Le cross-site scripting (XSS) est un problème pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, il est toujours considéré comme l'une des menaces les plus courantes au niveau du code. Ce type de vulnérabilité logicielle nous affecte depuis bien trop longtemps, et une alerte récente de CISA - dans le cadre de son mouvement Secureby-Design - cherche à le contrecarrer une fois pour toutes. Ils ont pour mission mondiale d'éliminer les classes de vulnérabilité à grande échelle, et cette mise en lumière de la sécurité pilotée par les développeurs peut vraiment faire bouger les choses et faire la différence, mais cela nécessitera l'engagement des entreprises intelligentes qui mettent leurs développeurs sur la voie du succès en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs Web sont peut-être notre passerelle vers toutes ces bonnes choses en ligne, mais malheureusement, ce n'est pas une bonne nouvelle. Le comportement inhérent des navigateurs Web peut être à l'origine de failles de sécurité. Les navigateurs ont commencé par faire confiance au balisage qu'ils voyaient et l'exécutaient sans aucun doute. 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 pour atteindre leurs objectifs pervers.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, prendre le contrôle de comptes et dégrader des sites Web ; il s'agit d'une vulnérabilité qui peut devenir très rapidement très dangereuse.
Voyons comment fonctionne le XSS, quels dommages peuvent être causés et comment les prévenir :
Comment fonctionne XSS ?
Le XSS se produit lorsqu'une entrée non fiable (souvent des données) est rendue en sortie sur une page mais interprétée à tort comme du code exécutable. Un attaquant peut placer du code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée qui, une fois renvoyé au navigateur, est ensuite exécuté au lieu d'être affiché sous forme de données.
Comme mentionné ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de distinguer les données du code exécutable. Le modèle de fonctionnement du Web est le suivant :
- L'utilisateur visite une page Web
- La page indique au navigateur quels fichiers charger et quels fichiers exécuter
- Le navigateur exécute le contenu de la page, sans poser de questions
Cette fonctionnalité a donné naissance à certaines des expériences interactives les plus géniales que nous apprécions sur le Web. Le revers de la médaille, c'est que cela a également entraîné 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 aucun doute. Il n'y a pas d'enquête plus approfondie et aucune mesure de détection n'a été mise en place.
Il existe trois types de XSS :
- XSS stocké
- XSS reflété
- DOM XSS
XSS stocké se produit 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 portable de l'utilisateur). Ce script sommaire 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 forum ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et paf, chaque utilisateur qui consulte ce commentaire exécute le script sans le savoir.
XSS reflété se produit lorsque les entrées de l'utilisateur sont renvoyées telles quelles dans le navigateur de l'utilisateur. Un exemple est un champ de recherche qui affiche « Vous avez recherché... » à l'utilisateur lors de la récupération des résultats de recherche.
Maintenant, imaginez que la recherche fonctionne en plaçant le terme de recherche 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é à ces mêmes paramètres et, honnêtement, la plupart des internautes le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site de phishing où elle saisit involontairement son mot de passe pour le site. Ils ne se rendent pas compte qu'un attaquant vient de voler la clé de leur compte.
DOM XSS est une variante relativement nouvelle de cette vulnérabilité. Il tire parti des structures de modèles complexes présentes dans de nombreux frameworks d'interface utilisateur tels que Angular et React.
Ces modèles permettent de créer du contenu dynamique et de riches applications d'interface utilisateur. S'ils ne sont pas utilisés correctement, ils peuvent être utilisés pour exécuter des attaques XSS.
Alors, voilà. Vous avez la portée de XSS en quelques mots. Examinons plus en détail comment il peut être utilisé de manière destructive.
Pourquoi le XSS est-il si dangereux ?
XSS peut être utilisé pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En gros, tout ce que JavaScript peut faire, les attaques XSS sont également capables de le faire.
Voici trois exemples d'attaques XSS :
- Utilisateurs de messagerie Yahoo se sont fait voler leurs cookies de session en utilisant XSS en 2015.
- Le Ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il s'agit toujours du malware qui se propage le plus rapidement de tous les temps, touchant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'inclusion de scripts malveillants dans les descriptions des produits. Cela a conduit à Attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont d'une simplicité trompeuse et très graves. Ils peuvent entraîner le vol de sessions, d'informations d'identification utilisateur 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égrader un site Web peut avoir des conséquences indésirables pour une entreprise.
Cependant, XSS peut être vaincu par un guerrier de la sécurité averti comme vous. La solution n'est pas compliquée et l'industrie a parcouru un long chemin depuis que XSS est devenu un exploit couramment utilisé.
Tu peux vaincre XSS.
La clé pour vaincre XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre saisie utilisateur sera renvoyée au client et où elle sera restituée. Dans le code HTML ou dans un extrait de code JavaScript.
Si les entrées de l'utilisateur n'ont pas besoin d'être renvoyées au navigateur, tant mieux. Mais si c'est le cas, il doit souvent être codé 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, validation et liste blanche ne sont pas des solutions infaillibles. L'encodage va encore plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas détecté par les stratégies de validation et de mise en liste blanche, l'encodage reprendra.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angulaire, ASP.NET MVC, et React.js sont des frameworks dans lesquels le codage HTML par défaut est utilisé. Vous devez spécifiquement dire à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks (par ex. Django et Printemps) disposent de bibliothèques standard pour la prévention XSS que vous pouvez facilement intégrer à votre code.
Le plus grand défi est d'apprendre à analyser toutes les manières dont les entrées des utilisateurs peuvent entrer dans un système afin de garder les yeux ouverts. Les paramètres de requête peuvent être porteurs d'attaques, tout comme les paramètres de publication. Suivez le flux de données dans l'ensemble de votre application et ne vous fiez à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Bloquez chaque donnée, inspectez-la et ne l'autorisez pas si elle semble malveillante. Encodez ensuite lors du rendu pour vous assurer que tout élément erroné oublié ne posera toujours pas de problème.
Exécutez ces stratégies et vos utilisateurs seront à l'abri des attaques via XSS. Jetez un coup d'œil au Aide-mémoire OWASP pour encore plus de conseils pour garder vos données sous contrôle.
Déjouez XSS et améliorez vos compétences en matière de sécurité.
XSS figure à la septième place de la liste des 10 principaux risques de sécurité Web 2017 de l'OWASP. 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 qui souhaitent adopter un état d'esprit axé sur la sécurité lorsqu'ils élaborent 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 cet esprit, pourquoi ne pas consulter notre Ressources pédagogiques pour en savoir plus sur XSS ? Après cela, vous pouvez commencer l'entraînement et la pratique qui mènent à votre maîtrise.
Vous pensez être prêt à détecter et à corriger les vulnérabilités XSS dès maintenant ? Relevez le défi sur la plateforme Secure Code Warrior.
Le cross-site scripting (XSS) utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, prendre le contrôle de comptes et dégrader des sites Web ; il s'agit d'une vulnérabilité qui peut devenir très rapidement très dangereuse. Voyons comment fonctionne le XSS, quels dommages peuvent être causés et comment les prévenir.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.
Veuillez réserver une démonstration.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Le cross-site scripting (XSS) est un problème pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, il est toujours considéré comme l'une des menaces les plus courantes au niveau du code. Ce type de vulnérabilité logicielle nous affecte depuis bien trop longtemps, et une alerte récente de CISA - dans le cadre de son mouvement Secureby-Design - cherche à le contrecarrer une fois pour toutes. Ils ont pour mission mondiale d'éliminer les classes de vulnérabilité à grande échelle, et cette mise en lumière de la sécurité pilotée par les développeurs peut vraiment faire bouger les choses et faire la différence, mais cela nécessitera l'engagement des entreprises intelligentes qui mettent leurs développeurs sur la voie du succès en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs Web sont peut-être notre passerelle vers toutes ces bonnes choses en ligne, mais malheureusement, ce n'est pas une bonne nouvelle. Le comportement inhérent des navigateurs Web peut être à l'origine de failles de sécurité. Les navigateurs ont commencé par faire confiance au balisage qu'ils voyaient et l'exécutaient sans aucun doute. 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 pour atteindre leurs objectifs pervers.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, prendre le contrôle de comptes et dégrader des sites Web ; il s'agit d'une vulnérabilité qui peut devenir très rapidement très dangereuse.
Voyons comment fonctionne le XSS, quels dommages peuvent être causés et comment les prévenir :
Comment fonctionne XSS ?
Le XSS se produit lorsqu'une entrée non fiable (souvent des données) est rendue en sortie sur une page mais interprétée à tort comme du code exécutable. Un attaquant peut placer du code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée qui, une fois renvoyé au navigateur, est ensuite exécuté au lieu d'être affiché sous forme de données.
Comme mentionné ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de distinguer les données du code exécutable. Le modèle de fonctionnement du Web est le suivant :
- L'utilisateur visite une page Web
- La page indique au navigateur quels fichiers charger et quels fichiers exécuter
- Le navigateur exécute le contenu de la page, sans poser de questions
Cette fonctionnalité a donné naissance à certaines des expériences interactives les plus géniales que nous apprécions sur le Web. Le revers de la médaille, c'est que cela a également entraîné 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 aucun doute. Il n'y a pas d'enquête plus approfondie et aucune mesure de détection n'a été mise en place.
Il existe trois types de XSS :
- XSS stocké
- XSS reflété
- DOM XSS
XSS stocké se produit 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 portable de l'utilisateur). Ce script sommaire 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 forum ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et paf, chaque utilisateur qui consulte ce commentaire exécute le script sans le savoir.
XSS reflété se produit lorsque les entrées de l'utilisateur sont renvoyées telles quelles dans le navigateur de l'utilisateur. Un exemple est un champ de recherche qui affiche « Vous avez recherché... » à l'utilisateur lors de la récupération des résultats de recherche.
Maintenant, imaginez que la recherche fonctionne en plaçant le terme de recherche 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é à ces mêmes paramètres et, honnêtement, la plupart des internautes le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site de phishing où elle saisit involontairement son mot de passe pour le site. Ils ne se rendent pas compte qu'un attaquant vient de voler la clé de leur compte.
DOM XSS est une variante relativement nouvelle de cette vulnérabilité. Il tire parti des structures de modèles complexes présentes dans de nombreux frameworks d'interface utilisateur tels que Angular et React.
Ces modèles permettent de créer du contenu dynamique et de riches applications d'interface utilisateur. S'ils ne sont pas utilisés correctement, ils peuvent être utilisés pour exécuter des attaques XSS.
Alors, voilà. Vous avez la portée de XSS en quelques mots. Examinons plus en détail comment il peut être utilisé de manière destructive.
Pourquoi le XSS est-il si dangereux ?
XSS peut être utilisé pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En gros, tout ce que JavaScript peut faire, les attaques XSS sont également capables de le faire.
Voici trois exemples d'attaques XSS :
- Utilisateurs de messagerie Yahoo se sont fait voler leurs cookies de session en utilisant XSS en 2015.
- Le Ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il s'agit toujours du malware qui se propage le plus rapidement de tous les temps, touchant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'inclusion de scripts malveillants dans les descriptions des produits. Cela a conduit à Attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont d'une simplicité trompeuse et très graves. Ils peuvent entraîner le vol de sessions, d'informations d'identification utilisateur 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égrader un site Web peut avoir des conséquences indésirables pour une entreprise.
Cependant, XSS peut être vaincu par un guerrier de la sécurité averti comme vous. La solution n'est pas compliquée et l'industrie a parcouru un long chemin depuis que XSS est devenu un exploit couramment utilisé.
Tu peux vaincre XSS.
La clé pour vaincre XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre saisie utilisateur sera renvoyée au client et où elle sera restituée. Dans le code HTML ou dans un extrait de code JavaScript.
Si les entrées de l'utilisateur n'ont pas besoin d'être renvoyées au navigateur, tant mieux. Mais si c'est le cas, il doit souvent être codé 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, validation et liste blanche ne sont pas des solutions infaillibles. L'encodage va encore plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas détecté par les stratégies de validation et de mise en liste blanche, l'encodage reprendra.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angulaire, ASP.NET MVC, et React.js sont des frameworks dans lesquels le codage HTML par défaut est utilisé. Vous devez spécifiquement dire à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks (par ex. Django et Printemps) disposent de bibliothèques standard pour la prévention XSS que vous pouvez facilement intégrer à votre code.
Le plus grand défi est d'apprendre à analyser toutes les manières dont les entrées des utilisateurs peuvent entrer dans un système afin de garder les yeux ouverts. Les paramètres de requête peuvent être porteurs d'attaques, tout comme les paramètres de publication. Suivez le flux de données dans l'ensemble de votre application et ne vous fiez à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Bloquez chaque donnée, inspectez-la et ne l'autorisez pas si elle semble malveillante. Encodez ensuite lors du rendu pour vous assurer que tout élément erroné oublié ne posera toujours pas de problème.
Exécutez ces stratégies et vos utilisateurs seront à l'abri des attaques via XSS. Jetez un coup d'œil au Aide-mémoire OWASP pour encore plus de conseils pour garder vos données sous contrôle.
Déjouez XSS et améliorez vos compétences en matière de sécurité.
XSS figure à la septième place de la liste des 10 principaux risques de sécurité Web 2017 de l'OWASP. 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 qui souhaitent adopter un état d'esprit axé sur la sécurité lorsqu'ils élaborent 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 cet esprit, pourquoi ne pas consulter notre Ressources pédagogiques pour en savoir plus sur XSS ? Après cela, vous pouvez commencer l'entraînement et la pratique qui mènent à votre maîtrise.
Vous pensez être prêt à détecter et à corriger les vulnérabilités XSS dès maintenant ? Relevez le défi sur la plateforme Secure Code Warrior.
Le cross-site scripting (XSS) est un problème pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, il est toujours considéré comme l'une des menaces les plus courantes au niveau du code. Ce type de vulnérabilité logicielle nous affecte depuis bien trop longtemps, et une alerte récente de CISA - dans le cadre de son mouvement Secureby-Design - cherche à le contrecarrer une fois pour toutes. Ils ont pour mission mondiale d'éliminer les classes de vulnérabilité à grande échelle, et cette mise en lumière de la sécurité pilotée par les développeurs peut vraiment faire bouger les choses et faire la différence, mais cela nécessitera l'engagement des entreprises intelligentes qui mettent leurs développeurs sur la voie du succès en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs Web sont peut-être notre passerelle vers toutes ces bonnes choses en ligne, mais malheureusement, ce n'est pas une bonne nouvelle. Le comportement inhérent des navigateurs Web peut être à l'origine de failles de sécurité. Les navigateurs ont commencé par faire confiance au balisage qu'ils voyaient et l'exécutaient sans aucun doute. 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 pour atteindre leurs objectifs pervers.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, prendre le contrôle de comptes et dégrader des sites Web ; il s'agit d'une vulnérabilité qui peut devenir très rapidement très dangereuse.
Voyons comment fonctionne le XSS, quels dommages peuvent être causés et comment les prévenir :
Comment fonctionne XSS ?
Le XSS se produit lorsqu'une entrée non fiable (souvent des données) est rendue en sortie sur une page mais interprétée à tort comme du code exécutable. Un attaquant peut placer du code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée qui, une fois renvoyé au navigateur, est ensuite exécuté au lieu d'être affiché sous forme de données.
Comme mentionné ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de distinguer les données du code exécutable. Le modèle de fonctionnement du Web est le suivant :
- L'utilisateur visite une page Web
- La page indique au navigateur quels fichiers charger et quels fichiers exécuter
- Le navigateur exécute le contenu de la page, sans poser de questions
Cette fonctionnalité a donné naissance à certaines des expériences interactives les plus géniales que nous apprécions sur le Web. Le revers de la médaille, c'est que cela a également entraîné 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 aucun doute. Il n'y a pas d'enquête plus approfondie et aucune mesure de détection n'a été mise en place.
Il existe trois types de XSS :
- XSS stocké
- XSS reflété
- DOM XSS
XSS stocké se produit 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 portable de l'utilisateur). Ce script sommaire 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 forum ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et paf, chaque utilisateur qui consulte ce commentaire exécute le script sans le savoir.
XSS reflété se produit lorsque les entrées de l'utilisateur sont renvoyées telles quelles dans le navigateur de l'utilisateur. Un exemple est un champ de recherche qui affiche « Vous avez recherché... » à l'utilisateur lors de la récupération des résultats de recherche.
Maintenant, imaginez que la recherche fonctionne en plaçant le terme de recherche 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é à ces mêmes paramètres et, honnêtement, la plupart des internautes le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site de phishing où elle saisit involontairement son mot de passe pour le site. Ils ne se rendent pas compte qu'un attaquant vient de voler la clé de leur compte.
DOM XSS est une variante relativement nouvelle de cette vulnérabilité. Il tire parti des structures de modèles complexes présentes dans de nombreux frameworks d'interface utilisateur tels que Angular et React.
Ces modèles permettent de créer du contenu dynamique et de riches applications d'interface utilisateur. S'ils ne sont pas utilisés correctement, ils peuvent être utilisés pour exécuter des attaques XSS.
Alors, voilà. Vous avez la portée de XSS en quelques mots. Examinons plus en détail comment il peut être utilisé de manière destructive.
Pourquoi le XSS est-il si dangereux ?
XSS peut être utilisé pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En gros, tout ce que JavaScript peut faire, les attaques XSS sont également capables de le faire.
Voici trois exemples d'attaques XSS :
- Utilisateurs de messagerie Yahoo se sont fait voler leurs cookies de session en utilisant XSS en 2015.
- Le Ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il s'agit toujours du malware qui se propage le plus rapidement de tous les temps, touchant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'inclusion de scripts malveillants dans les descriptions des produits. Cela a conduit à Attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont d'une simplicité trompeuse et très graves. Ils peuvent entraîner le vol de sessions, d'informations d'identification utilisateur 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égrader un site Web peut avoir des conséquences indésirables pour une entreprise.
Cependant, XSS peut être vaincu par un guerrier de la sécurité averti comme vous. La solution n'est pas compliquée et l'industrie a parcouru un long chemin depuis que XSS est devenu un exploit couramment utilisé.
Tu peux vaincre XSS.
La clé pour vaincre XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre saisie utilisateur sera renvoyée au client et où elle sera restituée. Dans le code HTML ou dans un extrait de code JavaScript.
Si les entrées de l'utilisateur n'ont pas besoin d'être renvoyées au navigateur, tant mieux. Mais si c'est le cas, il doit souvent être codé 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, validation et liste blanche ne sont pas des solutions infaillibles. L'encodage va encore plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas détecté par les stratégies de validation et de mise en liste blanche, l'encodage reprendra.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angulaire, ASP.NET MVC, et React.js sont des frameworks dans lesquels le codage HTML par défaut est utilisé. Vous devez spécifiquement dire à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks (par ex. Django et Printemps) disposent de bibliothèques standard pour la prévention XSS que vous pouvez facilement intégrer à votre code.
Le plus grand défi est d'apprendre à analyser toutes les manières dont les entrées des utilisateurs peuvent entrer dans un système afin de garder les yeux ouverts. Les paramètres de requête peuvent être porteurs d'attaques, tout comme les paramètres de publication. Suivez le flux de données dans l'ensemble de votre application et ne vous fiez à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Bloquez chaque donnée, inspectez-la et ne l'autorisez pas si elle semble malveillante. Encodez ensuite lors du rendu pour vous assurer que tout élément erroné oublié ne posera toujours pas de problème.
Exécutez ces stratégies et vos utilisateurs seront à l'abri des attaques via XSS. Jetez un coup d'œil au Aide-mémoire OWASP pour encore plus de conseils pour garder vos données sous contrôle.
Déjouez XSS et améliorez vos compétences en matière de sécurité.
XSS figure à la septième place de la liste des 10 principaux risques de sécurité Web 2017 de l'OWASP. 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 qui souhaitent adopter un état d'esprit axé sur la sécurité lorsqu'ils élaborent 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 cet esprit, pourquoi ne pas consulter notre Ressources pédagogiques pour en savoir plus sur XSS ? Après cela, vous pouvez commencer l'entraînement et la pratique qui mènent à votre maîtrise.
Vous pensez être prêt à détecter et à corriger les vulnérabilités XSS dès maintenant ? Relevez le défi sur la plateforme Secure Code Warrior.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Le cross-site scripting (XSS) est un problème pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, il est toujours considéré comme l'une des menaces les plus courantes au niveau du code. Ce type de vulnérabilité logicielle nous affecte depuis bien trop longtemps, et une alerte récente de CISA - dans le cadre de son mouvement Secureby-Design - cherche à le contrecarrer une fois pour toutes. Ils ont pour mission mondiale d'éliminer les classes de vulnérabilité à grande échelle, et cette mise en lumière de la sécurité pilotée par les développeurs peut vraiment faire bouger les choses et faire la différence, mais cela nécessitera l'engagement des entreprises intelligentes qui mettent leurs développeurs sur la voie du succès en matière de sécurité.
Alors, qu'est-ce que XSS exactement ?
Les navigateurs Web sont peut-être notre passerelle vers toutes ces bonnes choses en ligne, mais malheureusement, ce n'est pas une bonne nouvelle. Le comportement inhérent des navigateurs Web peut être à l'origine de failles de sécurité. Les navigateurs ont commencé par faire confiance au balisage qu'ils voyaient et l'exécutaient sans aucun doute. 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 pour atteindre leurs objectifs pervers.
Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, prendre le contrôle de comptes et dégrader des sites Web ; il s'agit d'une vulnérabilité qui peut devenir très rapidement très dangereuse.
Voyons comment fonctionne le XSS, quels dommages peuvent être causés et comment les prévenir :
Comment fonctionne XSS ?
Le XSS se produit lorsqu'une entrée non fiable (souvent des données) est rendue en sortie sur une page mais interprétée à tort comme du code exécutable. Un attaquant peut placer du code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée qui, une fois renvoyé au navigateur, est ensuite exécuté au lieu d'être affiché sous forme de données.
Comme mentionné ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de distinguer les données du code exécutable. Le modèle de fonctionnement du Web est le suivant :
- L'utilisateur visite une page Web
- La page indique au navigateur quels fichiers charger et quels fichiers exécuter
- Le navigateur exécute le contenu de la page, sans poser de questions
Cette fonctionnalité a donné naissance à certaines des expériences interactives les plus géniales que nous apprécions sur le Web. Le revers de la médaille, c'est que cela a également entraîné 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 aucun doute. Il n'y a pas d'enquête plus approfondie et aucune mesure de détection n'a été mise en place.
Il existe trois types de XSS :
- XSS stocké
- XSS reflété
- DOM XSS
XSS stocké se produit 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 portable de l'utilisateur). Ce script sommaire 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 forum ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et paf, chaque utilisateur qui consulte ce commentaire exécute le script sans le savoir.
XSS reflété se produit lorsque les entrées de l'utilisateur sont renvoyées telles quelles dans le navigateur de l'utilisateur. Un exemple est un champ de recherche qui affiche « Vous avez recherché... » à l'utilisateur lors de la récupération des résultats de recherche.
Maintenant, imaginez que la recherche fonctionne en plaçant le terme de recherche 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é à ces mêmes paramètres et, honnêtement, la plupart des internautes le remarqueraient à peine.
La victime clique sur le lien et est redirigée vers un site de phishing où elle saisit involontairement son mot de passe pour le site. Ils ne se rendent pas compte qu'un attaquant vient de voler la clé de leur compte.
DOM XSS est une variante relativement nouvelle de cette vulnérabilité. Il tire parti des structures de modèles complexes présentes dans de nombreux frameworks d'interface utilisateur tels que Angular et React.
Ces modèles permettent de créer du contenu dynamique et de riches applications d'interface utilisateur. S'ils ne sont pas utilisés correctement, ils peuvent être utilisés pour exécuter des attaques XSS.
Alors, voilà. Vous avez la portée de XSS en quelques mots. Examinons plus en détail comment il peut être utilisé de manière destructive.
Pourquoi le XSS est-il si dangereux ?
XSS peut être utilisé pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En gros, tout ce que JavaScript peut faire, les attaques XSS sont également capables de le faire.
Voici trois exemples d'attaques XSS :
- Utilisateurs de messagerie Yahoo se sont fait voler leurs cookies de session en utilisant XSS en 2015.
- Le Ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il s'agit toujours du malware qui se propage le plus rapidement de tous les temps, touchant un million d'utilisateurs en seulement 20 heures.
- eBay a autorisé l'inclusion de scripts malveillants dans les descriptions des produits. Cela a conduit à Attaques XSS contre les utilisateurs d'eBay.
Les attaques XSS sont d'une simplicité trompeuse et très graves. Ils peuvent entraîner le vol de sessions, d'informations d'identification utilisateur 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égrader un site Web peut avoir des conséquences indésirables pour une entreprise.
Cependant, XSS peut être vaincu par un guerrier de la sécurité averti comme vous. La solution n'est pas compliquée et l'industrie a parcouru un long chemin depuis que XSS est devenu un exploit couramment utilisé.
Tu peux vaincre XSS.
La clé pour vaincre XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre saisie utilisateur sera renvoyée au client et où elle sera restituée. Dans le code HTML ou dans un extrait de code JavaScript.
Si les entrées de l'utilisateur n'ont pas besoin d'être renvoyées au navigateur, tant mieux. Mais si c'est le cas, il doit souvent être codé 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, validation et liste blanche ne sont pas des solutions infaillibles. L'encodage va encore plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas détecté par les stratégies de validation et de mise en liste blanche, l'encodage reprendra.
De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angulaire, ASP.NET MVC, et React.js sont des frameworks dans lesquels le codage HTML par défaut est utilisé. Vous devez spécifiquement dire à ces frameworks de ne pas encoder en appelant une méthode spéciale.
La plupart des autres frameworks (par ex. Django et Printemps) disposent de bibliothèques standard pour la prévention XSS que vous pouvez facilement intégrer à votre code.
Le plus grand défi est d'apprendre à analyser toutes les manières dont les entrées des utilisateurs peuvent entrer dans un système afin de garder les yeux ouverts. Les paramètres de requête peuvent être porteurs d'attaques, tout comme les paramètres de publication. Suivez le flux de données dans l'ensemble de votre application et ne vous fiez à aucune donnée provenant de l'extérieur.
Pensez comme une patrouille frontalière. Bloquez chaque donnée, inspectez-la et ne l'autorisez pas si elle semble malveillante. Encodez ensuite lors du rendu pour vous assurer que tout élément erroné oublié ne posera toujours pas de problème.
Exécutez ces stratégies et vos utilisateurs seront à l'abri des attaques via XSS. Jetez un coup d'œil au Aide-mémoire OWASP pour encore plus de conseils pour garder vos données sous contrôle.
Déjouez XSS et améliorez vos compétences en matière de sécurité.
XSS figure à la septième place de la liste des 10 principaux risques de sécurité Web 2017 de l'OWASP. 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 qui souhaitent adopter un état d'esprit axé sur la sécurité lorsqu'ils élaborent 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 cet esprit, pourquoi ne pas consulter notre Ressources pédagogiques pour en savoir plus sur XSS ? Après cela, vous pouvez commencer l'entraînement et la pratique qui mènent à votre maîtrise.
Vous pensez être prêt à détecter et à corriger les vulnérabilités XSS dès maintenant ? Relevez le 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 là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Thèmes et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
