« XSS » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 34 : | Ligne 34 : | ||
Selon leur objectif, les pirates ont la possibilité d’utiliser les '''scripts intersites''' de différentes façons : | 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.''' | '''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 là du type de '''scripting intersite''' le plus dangereux et le plus utilisé, car cette technique ne demande pas une action initiale venant du hacker et qu’elle est capable de compromettre plusieurs internautes par la suite. Les champs de profil comme le nom d’utilisateur ou l’adresse électronique qui sont stockés sur le serveur et édités sur la page du compte sont des exemples de failles par script intersite stocké. | Il s’agit là du type de '''scripting intersite''' le plus dangereux et le plus utilisé, car cette technique ne demande pas une action initiale venant du hacker et qu’elle est capable de compromettre plusieurs internautes par la suite. Les champs de profil comme le nom d’utilisateur ou l’adresse électronique qui sont stockés sur le serveur et édités sur la page du compte sont des exemples de failles par script intersite stocké. | ||
=== | === Scripts intersites réfléchis === | ||
Les '''failles XSS réfléchies''' se développent au moment où la charge utile est gardée dans les informations envoyées par le navigateur au serveur. | Les '''failles XSS réfléchies''' se développent au moment où la charge utile est gardée dans les informations envoyées par le navigateur au serveur. | ||
À titre d’exemple, un pirate peut déposer un script malveillant dans les '''renseignements envoyés par le formulaire de recherche''' ou de contact d’un site web. Un cas très courant de scripting intersite réfléchi est le formulaire de recherche dans lequel les internautes envoient leur demande au serveur, et ils sont les seuls à trouver le résultat. | À titre d’exemple, un pirate peut déposer un script malveillant dans les '''renseignements envoyés par le formulaire de recherche''' ou de contact d’un site web. Un cas très courant de scripting intersite réfléchi est le formulaire de recherche dans lequel les internautes envoient leur demande au serveur, et ils sont les seuls à trouver le résultat. | ||
=== | === Scripteur intersite autonome === | ||
L’'''auto-scripting intersite''' se présente lorsque les hackers exploitent une faiblesse qui requiert un contexte particulièrement spécifique et des changements manuels. La seule victime possible est soi-même. | L’'''auto-scripting intersite''' se présente lorsque les hackers exploitent une faiblesse qui requiert un contexte particulièrement spécifique et des changements manuels. La seule victime possible est soi-même. | ||
Les '''transformations spécifiques''' incluent généralement des éléments comme les '''valeurs des cookies''' ou encore l’association de vos propres données à une charge utile. | Les '''transformations spécifiques''' incluent généralement des éléments comme les '''valeurs des cookies''' ou encore l’association de vos propres données à une charge utile. | ||
=== | === Cross-site scripting aveugle === | ||
Les '''attaques XSS aveugles''' se manifestent quand un attaquant n’est pas capable d’en apercevoir le résultat. Dans ces failles, la faiblesse est souvent située sur une page à laquelle seuls les internautes autorisés ont accès. | Les '''attaques XSS aveugles''' se manifestent quand un attaquant n’est pas capable d’en apercevoir le résultat. Dans ces failles, la faiblesse est souvent située sur une page à laquelle seuls les internautes autorisés ont accès. | ||
Le cas où un nom d’utilisateur est vulnérable au Cross-Site scripting, mais seulement depuis une page d’administration dédiée aux usagers de l’administration est un parfait exemple de ce type d’attaque. | Le cas où un nom d’utilisateur est vulnérable au Cross-Site scripting, mais seulement depuis une page d’administration dédiée aux usagers de l’administration est un parfait exemple de ce type d’attaque. | ||
=== | === Scripts intersites basés sur le DOM === | ||
Les '''attaques par XSS basées sur le DOM''' se constituent quand ce n’est pas le serveur en soi qui est vulnérable, mais le JavaScript de la page. | Les '''attaques par XSS basées sur le DOM''' se constituent quand ce n’est pas le serveur en soi qui est vulnérable, mais le JavaScript de la page. | ||
Version du 27 octobre 2023 à 08:50
Étymologie :
De l'anglais XSS est l'abréviation Cross-site Scripting.
Définition :
Le cross-site scripting est un type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, provoquant ainsi des actions sur les navigateurs web visitant la page. Les possibilités des XSS sont très larges puisque l'attaquant peut utiliser tous les langages pris en charge par le navigateur et de nouvelles possibilités sont régulièrement découvertes notamment avec l'arrivée de nouvelles technologies comme HTML5.
Fonctionnement :
Le Cross-site Scripting consiste à utiliser une plateforme web fragile, pour qu’il révoque un script malveillant aux internautes. Habituellement, il privilégie le langage JavaScript, toutefois, il est possible d’utiliser tous les langages de programmation côté client. Les hackers visent des sites web dont les fonctions sont fragiles et qui donnent accès aux utilisateurs, à savoir les formulaires de connexion, les barres de recherche, les zones de commentaire, etc.
Comme le JavaScript s’exécute sur la page du navigateur de la cible, des renseignements sensibles sur l’internaute authentifié sont exposés au vol lors de la session, permettant ainsi aux hackers de viser les administrateurs de sites et d’exposer les sites Web.
En fonction de la manière dont le code a été injecté, le contenu malveillant peut très bien ne pas se trouver sur la page authentique, mais elle peut devenir un élément de transition qui est totalement exclu du site qu’une fois au moment de l’exploitation. Cela peut engendrer l’illusion que le site web original est compromis, ce qui n’est pas le cas.
On distingue différentes façons de déclencher une attaque XSS. Tout d’abord, elle peut être créée automatiquement au moment du chargement de la page ou lorsqu’un internaute utilise sa souris sur des éléments caractéristiques d’une page tels que des hyperliens.
Le Cross-site Scripting peut aussi être réalisé directement, par exemple, dans un message d’email. Dans certains cas, une attaque par XSS ne cible pas de victime spécifique. Le pirate exploite juste une faiblesse dans un programme ou un site et espère juste 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) ;
- 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 là du type de scripting intersite le plus dangereux et le plus utilisé, car cette technique ne demande pas une action initiale venant du hacker et qu’elle est capable de compromettre plusieurs internautes par la suite. Les champs de profil comme le nom d’utilisateur ou l’adresse électronique qui sont stockés sur le serveur et édités sur la page du compte sont des exemples de failles par script intersite stocké.
Scripts intersites réfléchis
Les failles XSS réfléchies se développent au moment où la charge utile est gardée dans les informations envoyées par le navigateur au serveur.
À titre d’exemple, un pirate peut déposer un script malveillant dans les renseignements envoyés par le formulaire de recherche ou de contact d’un site web. Un cas très courant de scripting intersite réfléchi est le formulaire de recherche dans lequel les internautes envoient leur demande au serveur, et ils sont les seuls à trouver le résultat.
Scripteur intersite autonome
L’auto-scripting intersite se présente lorsque les hackers exploitent une faiblesse qui requiert un contexte particulièrement spécifique et des changements manuels. La seule victime possible est soi-même.
Les transformations spécifiques incluent généralement des éléments comme les valeurs des cookies ou encore l’association de vos propres données à une charge utile.
Cross-site scripting aveugle
Les attaques XSS aveugles se manifestent quand un attaquant n’est pas capable d’en apercevoir le résultat. Dans ces failles, la faiblesse est souvent située sur une page à laquelle seuls les internautes autorisés ont accès.
Le cas où un nom d’utilisateur est vulnérable au Cross-Site scripting, mais seulement depuis une page d’administration dédiée aux usagers de l’administration est un parfait exemple de ce type d’attaque.
Scripts intersites basés sur le DOM
Les attaques par XSS basées sur le DOM se constituent quand ce n’est pas le serveur en soi qui est vulnérable, mais le JavaScript de la page.
Comme le langage est utilisé pour donner plus d’interactivité à la page, les arguments dans l’URL peuvent être utilisés pour changer la page suite au chargement. En transformant le DOM quand il ne nettoie pas les valeurs qui proviennent de l’internaute, les pirates informatiques sont capables d’associer à la page un code malveillant.
Le cas d’une faille XSS basée sur le DOM est le moment où la plateforme web transforme le choix de la langue par défaut pour celle qui est offerte dans l’URL.
Référence :
- Wikipédia
- ↑ (en) DOM-Based cross-site scripting [archive]
- ↑ (en) http://namb.la/popular/tech.html [archive] : explication et source du ver
- ↑ (en)Apache Infrastructure Team, « » [archive], sur The Apache Software Foundation, 2010 (consulté le 30 août 2012)
- ↑ « » [archive], sur 01net.com, 23 septembre 2014 (consulté le 25 septembre 2014)
- ↑ Jeuxvideo.com cible d’une tentative de piratage [archive], lemonde.fr, 23 aou