« XSS » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (10 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Fichier:Capture d’écran 2023-10-27 à 10.56.31.png|vignette]] | |||
== Étymologie : == | == Étymologie : == | ||
De l'anglais XSS | De l'anglais XSS, abréviation Cross-site Scripting.<blockquote>« Le problème n'est pas simplement le "scripting", et il n'y a pas forcément quelque chose entre plusieurs sites. Alors pourquoi ce nom ? En fait, le nom a été donné quand le problème était moins bien compris, et c'est resté. Croyez-moi, nous avions des choses plus importantes à faire que de réfléchir à un meilleur nom. »</blockquote>— Mark Slemko, | ||
== Définition : == | == Définition : == | ||
Le '''cross-site scripting''' est | Le '''cross-site scripting''' (XSS) est une vulnérabilité courante dans les sites web, permettant d'insérer du contenu malveillant dans une page. Cela peut entraîner des actions non désirées sur les navigateurs des visiteurs. Les XSS offrent une grande variété de possibilités, car un attaquant peut exploiter tous les langages pris en charge par le navigateur. De plus, de nouvelles opportunités sont régulièrement découvertes, notamment avec l'avènement de technologies telles qu'HTML5. Cette faille de sécurité existe depuis les années 2000. Un exemple emblématique de son exploitation remonte à 2005, lorsque le pirate Samy Kamkar a exploité une faille sur le réseau social MySpace, lui permettant d'accumuler plus d'un million d'amis en à peine une vingtaine d'heures. | ||
== Fonctionnement == | |||
Le Cross-site Scripting (XSS) implique l'exploitation d'une '''vulnérabilité d'une plateforme web''' afin d'injecter un script malveillant à l'insu des utilisateurs. Habituellement, ce type d'attaque se base sur le langage JavaScript, mais il est également possible d'utiliser d'autres langages de programmation côté client. Les pirates ciblent principalement des sites web dont les fonctionnalités présentent des failles de sécurité, telles que les formulaires de connexion, les barres de recherche, les zones de commentaires, entre autres. | |||
Étant donné que le code JavaScript '''s'exécute directement sur le navigateur de l'utilisateur ciblé''', il peut exposer des informations sensibles de l'internaute authentifié, mettant ainsi en danger la session. Cela permet aux pirates de cibler les administrateurs de sites web et de potentiellement compromettre la sécurité des sites eux-mêmes. | |||
Selon la méthode d'injection du code, le contenu malveillant peut ne pas être directement présent sur la page authentique, mais plutôt agir comme un élément de transition qui n'est activé que lors de l'exploitation. Cette situation peut créer l'illusion que le site web d'origine est compromis, alors qu'en réalité, ce n'est pas le cas. | |||
Il existe diverses méthodes pour déclencher une attaque XSS. Tout d'abord, elle peut être provoquée de manière automatique lors du chargement de la page ou lorsque l'utilisateur interagit avec certains éléments de la page, tels que des liens. | |||
Le Cross-site Scripting peut | Le Cross-site Scripting peut également être réalisé de manière directe, par exemple, en utilisant un message électronique. Dans certains cas, une attaque XSS ne vise pas une victime spécifique, le pirate exploite simplement une vulnérabilité dans un programme ou un site web, espérant qu'un visiteur tombe dessus. | ||
En fonction de la grandeur de la frappe, la faille XSS peut engendrer : | En fonction de la grandeur de la frappe, la faille XSS peut engendrer : | ||
| Ligne 24 : | Ligne 22 : | ||
* la '''compromission des comptes''' utilisateurs ; | * la '''compromission des comptes''' utilisateurs ; | ||
* l’'''activation des trojans '''; | * l’'''activation des trojans '''; | ||
* la '''modification de page''' (dans le but de duper les utilisateurs et les conduire à divulguer des renseignements confidentiels) ; | * la '''modification de page''' (dans le but de duper les utilisateurs et les conduire à divulguer des renseignements confidentiels) ;[[Fichier:Cross-site scripting attack sequence diagram - en.png|vignette|Le diagramme de séquence d'une attaque cross-site scripting.]] | ||
* la '''révélation des cookies de session''' (qui permet à un pirate d’usurper l’identité d’un utilisateur et d’exploiter leur compte personnel). | * la '''révélation des cookies de session''' (qui permet à un pirate d’usurper l’identité d’un utilisateur et d’exploiter leur compte personnel). | ||
| Ligne 37 : | Ligne 35 : | ||
'''Les attaques par XSS stockées se manifestent lorsqu’un pirate dépose leur charge utile dans un serveur affecté, ce qui conduit le site à propager un code malveillant aux autres internautes.''' | '''Les attaques par XSS stockées se manifestent lorsqu’un pirate dépose leur charge utile dans un serveur affecté, ce qui conduit le site à propager un code malveillant aux autres internautes.''' | ||
Il | Il s'agit du type de '''scripting intersite''' le plus dangereux et le plus couramment employé. Cette technique ne requiert pas d'action initiale de la part du pirate, et elle est susceptible de compromettre plusieurs internautes par la suite. Les champs de profil tels que le nom d'utilisateur ou l'adresse électronique, qui sont enregistrés sur le serveur et modifiables sur la page du compte, sont des exemples de vulnérabilités liées au scripting intersite stocké. | ||
=== Scripts intersites réfléchis === | === Scripts intersites réfléchis === | ||
Les '''failles XSS réfléchies''' | Les '''failles XSS réfléchies''' surviennent lorsque la charge malveillante est incluse dans les données transmises par le navigateur au serveur. | ||
Par exemple, un pirate pourrait insérer un script malicieux dans les informations envoyées via un formulaire de recherche ou de contact sur un site web. Un exemple fréquent de scripting intersite réfléchi se trouve dans les formulaires de recherche, où les utilisateurs envoient leurs requêtes au serveur et visualisent ensuite les résultats. | |||
=== Scripteur intersite autonome === | === Scripteur intersite autonome === | ||
L''''auto-scripting intersite''' se produit lorsque les pirates exploitent une vulnérabilité nécessitant un contexte particulièrement spécifique et des ajustements manuels. Dans ce cas, la seule personne qui pourrait être victime est l'auteur de l'exploit. | |||
Ces ajustements spécifiques impliquent souvent la manipulation d'éléments tels que les valeurs des cookies ou l'association de vos propres données à une charge malveillante. | |||
=== Cross-site scripting aveugle === | === Cross-site scripting aveugle === | ||
Les '''attaques XSS aveugles''' | Les '''attaques XSS aveugles''' surviennent lorsque l'attaquant ne peut pas observer directement les résultats de son action. Dans de telles vulnérabilités, la faiblesse se trouve généralement sur une page à laquelle seuls les utilisateurs autorisés ont accès. | ||
Un exemple parfait de ce type d'attaque est le cas où un nom d'utilisateur est vulnérable au Cross-Site Scripting, mais seulement à partir d'une page d'administration réservée aux utilisateurs du système d'administration. | |||
=== Scripts intersites basés sur le DOM === | === Scripts intersites basés sur le DOM === | ||
Les | Les attaques par XSS basées sur le DOM se produisent lorsque ce n'est pas le serveur lui-même qui est vulnérable, mais plutôt le code JavaScript de la page. | ||
Étant donné que le langage JavaScript est utilisé pour accroître l'interactivité de la page, les arguments inclus dans l'URL peuvent être exploités pour modifier le contenu de la page après son chargement initial. Lorsque le Document Object Model (DOM) ne nettoie pas correctement les données provenant des utilisateurs, les pirates informatiques peuvent insérer un code malveillant dans la page. | |||
Un exemple concret d'une vulnérabilité XSS basée sur le DOM se produit lorsque la plateforme web permet de changer la langue par défaut en fonction de ce qui est spécifié dans l'URL. | |||
== Référence : == | == Référence : == | ||
# | # https://fr.wikipedia.org/wiki/Cross-site_scripting | ||
# | #[https://guardia.school/boite-a-outils/en-quoi-consiste-une-attaque-par-xss.html#:~:text=Le%20Cross%2Dsite%20Scripting%20(XSS,de%20chaque%20visite%20du%20site. https://guardia.school/boite-a-outils/en-quoi-consiste-une-attaque-par-xss.html#:~:text=Le%20Cross%2Dsite%20Scripting%20(XSS,de%20chaque%20visite%20du%20site.] | ||
# | #https://icesi.fr/5_Faille-XSS-ou-le-Cross-Site-Scripting.html | ||
# | |||
Dernière version du 27 octobre 2023 à 09:57
Étymologie :
De l'anglais XSS, abréviation Cross-site Scripting.
« Le problème n'est pas simplement le "scripting", et il n'y a pas forcément quelque chose entre plusieurs sites. Alors pourquoi ce nom ? En fait, le nom a été donné quand le problème était moins bien compris, et c'est resté. Croyez-moi, nous avions des choses plus importantes à faire que de réfléchir à un meilleur nom. »
— Mark Slemko,
Définition :
Le cross-site scripting (XSS) est une vulnérabilité courante dans les sites web, permettant d'insérer du contenu malveillant dans une page. Cela peut entraîner des actions non désirées sur les navigateurs des visiteurs. Les XSS offrent une grande variété de possibilités, car un attaquant peut exploiter tous les langages pris en charge par le navigateur. De plus, de nouvelles opportunités sont régulièrement découvertes, notamment avec l'avènement de technologies telles qu'HTML5. Cette faille de sécurité existe depuis les années 2000. Un exemple emblématique de son exploitation remonte à 2005, lorsque le pirate Samy Kamkar a exploité une faille sur le réseau social MySpace, lui permettant d'accumuler plus d'un million d'amis en à peine une vingtaine d'heures.
Fonctionnement
Le Cross-site Scripting (XSS) implique l'exploitation d'une vulnérabilité d'une plateforme web afin d'injecter un script malveillant à l'insu des utilisateurs. Habituellement, ce type d'attaque se base sur le langage JavaScript, mais il est également possible d'utiliser d'autres langages de programmation côté client. Les pirates ciblent principalement des sites web dont les fonctionnalités présentent des failles de sécurité, telles que les formulaires de connexion, les barres de recherche, les zones de commentaires, entre autres.
Étant donné que le code JavaScript s'exécute directement sur le navigateur de l'utilisateur ciblé, il peut exposer des informations sensibles de l'internaute authentifié, mettant ainsi en danger la session. Cela permet aux pirates de cibler les administrateurs de sites web et de potentiellement compromettre la sécurité des sites eux-mêmes.
Selon la méthode d'injection du code, le contenu malveillant peut ne pas être directement présent sur la page authentique, mais plutôt agir comme un élément de transition qui n'est activé que lors de l'exploitation. Cette situation peut créer l'illusion que le site web d'origine est compromis, alors qu'en réalité, ce n'est pas le cas.
Il existe diverses méthodes pour déclencher une attaque XSS. Tout d'abord, elle peut être provoquée de manière automatique lors du chargement de la page ou lorsque l'utilisateur interagit avec certains éléments de la page, tels que des liens.
Le Cross-site Scripting peut également être réalisé de manière directe, par exemple, en utilisant un message électronique. Dans certains cas, une attaque XSS ne vise pas une victime spécifique, le pirate exploite simplement une vulnérabilité dans un programme ou un site web, espérant qu'un visiteur tombe dessus.
En fonction de la grandeur de la frappe, la faille XSS peut engendrer :
- la compromission des comptes utilisateurs ;
- l’activation des trojans ;
- la modification de page (dans le but de duper les utilisateurs et les conduire à divulguer des renseignements confidentiels) ;
Le diagramme de séquence d'une attaque cross-site scripting. - la révélation des cookies de session (qui permet à un pirate d’usurper l’identité d’un utilisateur et d’exploiter leur compte personnel).
La réussite d’une attaque XSS peut engendrer des impacts dévastateurs pour la réputation d’une activité en ligne ou encore la relation avec les clients. Inopportunément, les failles à l’origine de ces attaques sont très répandues.
Les différents types d'attaques :
Selon leur objectif, les pirates ont la possibilité d’utiliser les scripts intersites de différentes façons :
Scripts intersites sauvegardés (persistants)
Les attaques par XSS stockées se manifestent lorsqu’un pirate dépose leur charge utile dans un serveur affecté, ce qui conduit le site à propager un code malveillant aux autres internautes.
Il s'agit du type de scripting intersite le plus dangereux et le plus couramment employé. Cette technique ne requiert pas d'action initiale de la part du pirate, et elle est susceptible de compromettre plusieurs internautes par la suite. Les champs de profil tels que le nom d'utilisateur ou l'adresse électronique, qui sont enregistrés sur le serveur et modifiables sur la page du compte, sont des exemples de vulnérabilités liées au scripting intersite stocké.
Scripts intersites réfléchis
Les failles XSS réfléchies surviennent lorsque la charge malveillante est incluse dans les données transmises par le navigateur au serveur.
Par exemple, un pirate pourrait insérer un script malicieux dans les informations envoyées via un formulaire de recherche ou de contact sur un site web. Un exemple fréquent de scripting intersite réfléchi se trouve dans les formulaires de recherche, où les utilisateurs envoient leurs requêtes au serveur et visualisent ensuite les résultats.
Scripteur intersite autonome
L'auto-scripting intersite se produit lorsque les pirates exploitent une vulnérabilité nécessitant un contexte particulièrement spécifique et des ajustements manuels. Dans ce cas, la seule personne qui pourrait être victime est l'auteur de l'exploit.
Ces ajustements spécifiques impliquent souvent la manipulation d'éléments tels que les valeurs des cookies ou l'association de vos propres données à une charge malveillante.
Cross-site scripting aveugle
Les attaques XSS aveugles surviennent lorsque l'attaquant ne peut pas observer directement les résultats de son action. Dans de telles vulnérabilités, la faiblesse se trouve généralement sur une page à laquelle seuls les utilisateurs autorisés ont accès.
Un exemple parfait de ce type d'attaque est le cas où un nom d'utilisateur est vulnérable au Cross-Site Scripting, mais seulement à partir d'une page d'administration réservée aux utilisateurs du système d'administration.
Scripts intersites basés sur le DOM
Les attaques par XSS basées sur le DOM se produisent lorsque ce n'est pas le serveur lui-même qui est vulnérable, mais plutôt le code JavaScript de la page.
Étant donné que le langage JavaScript est utilisé pour accroître l'interactivité de la page, les arguments inclus dans l'URL peuvent être exploités pour modifier le contenu de la page après son chargement initial. Lorsque le Document Object Model (DOM) ne nettoie pas correctement les données provenant des utilisateurs, les pirates informatiques peuvent insérer un code malveillant dans la page.
Un exemple concret d'une vulnérabilité XSS basée sur le DOM se produit lorsque la plateforme web permet de changer la langue par défaut en fonction de ce qui est spécifié dans l'URL.