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は、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、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.
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
レポートを表示するデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、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.
目次
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するダウンロード
%20(1).avif)
.avif)
