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 aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostración
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.
Haga clic en el enlace siguiente y descargue el PDF de este recurso.
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Mostrar el informeReserve una demostración
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.
Índice
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostraciónDescargarRecursos para ayudarle a empezar
Temas y contenidos de formación sobre el código seguro
Nuestro contenido de vanguardia evoluciona constantemente para adaptarse al panorama en constante cambio del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la IA hasta la inyección de XQuery, ofrecidos para una variedad de puestos, desde arquitectos hasta ingenieros, pasando por jefes de producto y control de calidad. Descubra una visión general de lo que nuestro catálogo de contenidos tiene para ofrecer por tema y por función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para ayudarle a empezar
Cybermon está de vuelta: las missions Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible todo el año en SCW. Implemente desafíos de seguridad avanzados relacionados con la IA y el LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la ley sobre ciberresiliencia: lo que significa para el desarrollo de software seguro desde el diseño.
Descubra qué exige la ley europea sobre ciberresiliencia (CRA), a quién se aplica y cómo los equipos de ingenieros pueden prepararse mediante prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el refuerzo de las capacidades de los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 da inicio a nuestra serie de 10 partes titulada «Facilitadores del éxito», mostrando cómo combinar la codificación segura con resultados comerciales, como la reducción de riesgos y la rapidez, para garantizar la madurez a largo plazo de los programas.
