3.3 [Advanced] Attaques XSS : découvrir
Bascule dans une sombre histoire d'Underwold de la cyber-sécurité et approfondis tes connaissances sur les attaques Cross-Site-Scripting (XSS) !
Objectifs
- Pouvoir expliquer la différence entre DOM-based, reflected et persistent XSS
- Reconnaître des failles XSS potentielles dans un code
- Être capable de mener plusieurs types d'attaques XSS simples
Cyber-security Underworld
[Rappel : frustré·e de te faire spoiler la dernière saison de Jeu des Trônes alors que tu campes dans une forêt à l’autre bout du monde, tu as décidé de créer un réseau social alternatif épuré de toutes allusions à des productions télévisuelles. Ta grand-mère, darkMereGrand_93, t'a alors interpellé·e sur les risques d'attaques XSS, ce qui t'a entraîné·e dans le monde merveilleux de la cyber-sécurité.]
« Pas si compliquées que ça, les attaques XSS », penses-tu en terminant de savourer une boîte de haricots blancs pour la quatorzième fois de la semaine. Mais alors qu'une douce somnolence post-dînatoire t'étreint, il te semble apercevoir une figure étrange dans le feu de camp qui se consume lentement...
... darkMereGrand_93 ?!
Avant que tu aies le temps de comprendre quoi que ce soit, te voici sur un quai de métro blafard.
– Tu pensais en avoir fini avec les attaques XSS ? demande la voix désincarnée de ta mamie (bien que cela devrait être le cadet de tes soucis, tu te demandes si la 4G passe ici). – Que nenni ! L'Underworld de la sécurité web est bien plus vaste que ça !
Un wagon apparaît. Sans vraiment pouvoir expliquer pourquoi, tu montes à bord.
Là, un laptop oublié sur un siège t'attend. Tu l'allumes et, tandis que les portes se referment sur toi, tu comprends enfin ce qui t'arrive...
... une quête sur les failles XSS, encore !
Il existe 3 types d'attaques XSS
Une attaque XSS commence du côté client d'un site web, c'est-à-dire dans le navigateur de l'utilisateur du site. Le script malveillant est alors injecté au sein du site victime, par exemple via un champ d'input. Le code corrompu peut ensuite connaître deux destins : soit il reste du côté client (toute l'attaque se passe alors dans le navigateur ; il s'agit d'une attaque DOM-based), soit il continue son chemin et est envoyé au serveur.
Arrivé au serveur, il peut ne pas être stocké dans la base de données du site piraté (on dit alors qu'il est non-persistant, ou reflected). Ou bien il peut, au contraire, réussir à être stocké dans la base de données du site piraté (on dit alors qu'il est persistant, ou stored).
Cette classification se résume ainsi :
- DOM-based* (parfois appelé « Type-0 »)
- Persistant / Stored (parfois appelé « Type-I »)
- Non-persistant / Reflected (parfois appelé « Type-II »)
Voyons plus en détails comment fonctionnent ces différents types de XSS !
DOM-based XSS
Ce type de XSS permet d'effectuer un piratage qui se cantonne au côté client du site, c'est-à-dire que l'attaque n'atteint jamais le serveur et que tout se passe dans le navigateur de l'utilisateur piégé (on dit alors que la source du code malveillant – source en anglais – et l'élément récepteur qui exécutera le code – sink, en anglais, soit littéralement l'évier – sont tous les deux du côté client). Cette particularité en fait des attaques très difficiles à détecter pour les développeurs·euses responsables des sites victimes, d'où le peu de statistiques disponibles concernant leur fréquence.
Comme dans les étapes précédentes, consulte cette animation, puis lis les parties « DOM-based XSS » et « DOM-based XSS invisible to the server » de cet article.
Consolide ce que tu viens d'apprendre en consultant cet article (arrête-toi avant la partie « Input & Output so called Source & Sink »).
Explication détaillée mais claire des DOM-based XSS, avec des exemples concrets (à lire jusqu'à la partie « Input & Output so called Source & Sink » exclue).
Une description des DOM-based XSS dans les parties « DOM-based XSS » et « DOM-based XSS invisible to the server ».
Une explication en quelques clics grâce à une animation interactive (et c'est re-mignon).
Reflected XSS
Ce type de XSS est nommé « reflected » car le code malveillant injecté est transmis (avec le reste de la page victime) du navigateur au serveur, puis celui-ci renvoie vers le navigateur la page avec le script pirate qui s'y est incorporé – en d'autres termes, il reflète le code malveillant tel un miroir.
Comme dans l'étape précédente, joue avec cette animation, puis lis la partie « Reflected XSS » de cet article.
Une description des reflected XSS dans la partie « Reflected XSS ».
Une explication en quelques clics grâce à une animation interactive (et c'est toujours aussi mignon).
Stored XSS
Ici, le script malveillant injecté par l'attaquant est stocké de manière permanente dans la base de données du site victime. Lorsque les utilisateurs consultent ce site, la page abritant le script malveillant est envoyée au navigateur comme s'il s'agissait d'une page saine. Il s'agit du type d'attaque le plus dangereux, car il est possible d'atteindre un grand nombre d'utilisateurs.
Découvre une illustration de ce qu'est un stored XSS en interagissant avec cette animation.
Pour consulter les animations en illimité, crée-toi un compte sur hacksplaining, c'est gratuit et ça prend deux minutes !
Lis ensuite les parties « Actors in an XSS attack », « An example attack scenario » et « How the example attack works » de ce tutoriel pour comprendre le mécanisme d'un stored XSS.
Regarde cette démonstration (à partir de 3 minutes 15) pour voir comment ce type d'attaques peut être utilisé pour voler les cookies d'un utilisateur.
Si jamais tu as besoin d'un petit rappel sur ce que sont les cookies, consulte cette vidéo (du début jusqu'à 2 minutes 11) avant d'enchaîner sur la démonstration.
Une démonstration vidéo expliquant comment le stored XSS peut permettre le vol de cookies.
Petit rappel en animation (attention, ça donne faim...).
Une description claire des stored XSS dans les parties « Actors in an XSS attack », « An example attack scenario » et « How the example attack works ».
Une explication en quelques clics grâce à une animation interactive (et en plus, c'est mignon !).
Par où passent les attaques ?
Les attaques XSS peuvent être plus ou moins sophistiquées, nous n'établirons donc pas de liste exhaustive des failles exploitables. Néanmoins, il existe quelques ventres mous bien connus des pirates, qui les cherchent en priorité pour atteindre un site.
Les grands types de failles XSS sont décrits ici (parties « Input handling contexts » et « Why context matters »). Tu peux y voir que, dès lors qu'un utilisateur peut entrer des données (en ajoutant du code malveillant à une url ou en le tapant dans un input) qui vont s'insérer quelque part dans le code source de la page visée, un risque d'attaque existe. Par exemple, l'injection peut se loger entre deux <div>, en tant qu'événement dans un attribut (ex : <img src=nothing.png onerror=alert('Hacked!')>) ou encore via le pseudo-protocol javascript:, qui permet notamment de piéger des <a href=""> .
Une manière de mieux se représenter quelles failles peuvent être exploitées par les attaques XSS est d'aller voir (sans t'attarder outre-mesure) la section « XSS in HTML/Applications » de ce cheatsheet de l'OWASP.
Dans la section « XSS in HTML/Applications », liste des principaux payloads utilisés en HTML.
Exemple d'exploitation des événements JavaScript pour mener une attaque XSS.
Parties « Input handling contexts » et « Why context matters » – présentation générale des principales failles XSS.
Challenge
C'est parti !
Coincé·e dans l'Underwold de la cyber-sécurité, tu t'attelles à continuer les challenges du XSS game proposé par Google.
- Trouve les réponses aux challenges 3 à 5. Si tu es très motivé·e, résous aussi le 6 !
- Inscris tes réponses dans un gist (ex :
Challenge 3 : <a href=alert("blop")>,Challenge 4 : <img src="bip.png" onerror=alert("blop")>, etc.). - Partage le lien de ton gist en guise de solution au challenge.
Critères de validation
- Ouvrir XSS Game dans une fenêtre de navigation privée. Pour chaque challenge, copier-coller les réponses fournies. Le challenge doit être résolu par la réponse collée.
- Les challenges 3 à 5 doivent être résolus par les réponses de l'élève.