指令

注入 - XSS

Le cross-site scripting, également connu sous le nom de XSS, est un autre type de vulnérabilité d'injection qui conduit à l'évaluation d'un script contrôlé par un attaquant dans le navigateur d'un autre utilisateur. XSS peut également être considéré comme une vulnérabilité d'injection HTML/JavaScript.

L'impact d'une vulnérabilité XSS dépend fortement du contexte dans lequel elle se trouve. Cela va de la possibilité d'extraire des informations de la page sur laquelle le script est exécuté à la modification de l'état de la page pour effectuer des actions en tant que victime sur la page.

Examinons les types de XSS que vous pouvez rencontrer.

Types de XSS

Le XSS peut être divisé en plusieurs compartiments pour aider à les distinguer. Ils sont classés en fonction de la manière dont la charge utile est livrée et de l'emplacement du point d'entrée.

Vecteur de livraison de la charge utile (stocké ou réfléchi)

Un attaquant peut fournir une charge utile XSS de deux manières :

XSS stocké: Par le biais de données contrôlées par l'utilisateur stockées, par exemple, dans une base de données où les données sont transmises à d'autres utilisateurs
XSS reflété: via une charge utile fournie par l'utilisateur et transmise via l'URL ou la chaîne de requête consultée par un utilisateur

La distinction essentielle est qu'un XSS reflété dépend généralement de l'interaction de l'utilisateur et n'a d'impact que sur l'utilisateur qui ouvre le lien contenant la charge utile malveillante. Cependant, un fichier XSS stocké peut être exécuté contre un ou plusieurs utilisateurs en ouvrant simplement certaines pages qui affichent la charge utile.

Emplacement de la charge utile (DOM ou non-DOM)

L'emplacement dans lequel une charge utile est injectée détermine si vous classez la vulnérabilité comme étant une vulnérabilité « DOM » ou non. Cela fait référence à la distinction entre l'endroit où la charge utile est rendue :

XSS non DOM: La charge utile est rendue en HTML, que ce soit à l'intérieur d'une balise ou d'un attribut
DOM XSS: La charge utile est rendue dans JavaScript, comme une <script>balise `` ou un gestionnaire d'événements tel que `onclick=

XSS - Primitives de défense

Dans cette section, nous examinerons les principes des primitives qui sous-tendent la défense contre le XSS. Il est essentiel d'en comprendre les bases, mais dans la pratique, vous devriez vous fier à votre bibliothèque de modèles pour une protection de 99 % contre XSS.

Lorsque vous écrivez des modèles qui sont rendus sous forme de balisage ou de code s'exécutant dans un navigateur, la clé de la protection contre le XSS est *encodage*. Dans ce contexte, l'encodage consiste à prendre une séquence de caractères et à la transformer en un format qui est traité d'une manière spécifique par l'interpréteur.

Toutefois, le type de codage à utiliser dépend de l'emplacement ou du contexte dans lequel les données seront utilisées.

À l'intérieur d'une balise, comme `<div>Entrée utilisateur ici</div>` : **Encodage HTML**
À l'intérieur d'un attribut, comme `<input placeholder="User input here"></input>` : **Encodage des attributs**
Dans Javascript, comme `<script>x = « Entrée utilisateur ici » ;</script>` : **Encodage Javascript **

Certains frameworks renonceront à l'encodage comme principal moyen de défense et utiliseront plutôt la désinfection pour supprimer une valeur de tout contenu susceptible d'être dangereux. Il s'agit d'un processus beaucoup plus complexe qui comporte de nombreux cas extrêmes à prendre en compte. Il n'est pas recommandé de mettre en œuvre vos propres routines de désinfection.

示例

Jetons un coup d'œil à quelques exemples dans différentes langues pour voir à quoi tout cela ressemble en action.

C# - Non sécurisé : Razor

Si un objet `IHTMLContent` est préfixé par un `@`, la valeur est directement placée dans le modèle sans aucun encodage.

@Html .Raw (extrait HTML)

C# - Sécurisé : Razor

Par défaut, toute chaîne préfixée par un « @ » est du code HTML échappé dans les modèles Razor.

@htmlSnippet

Java - Sécurisé : JSP

Lorsque vous utilisez c:out, il s'échappe au format XML par défaut (qui peut être modifié avec la propriété EscapeXML), ce qui protège contre le XSS dans un contexte HTML, mais pas dans d'autres contextes.

<div><c:out value="<%= author %>" /></div>

Java - Sécurisé : (fnxml)

Comme ci-dessus, vous pouvez également appeler directement fn:EscapeXML`, ce qui permettra au XML d'échapper à l'entrée qui lui est donnée. Cela ne protégera également que dans un contexte HTML.

<div>$ {fn:EscapeXML (auteur)}</div>

Javascript - Non sécurisé : Angular InnerHTML

En spécifiant la propriété InnerHTML, comme son nom l'indique, vous serez exposé au risque XSS en raison de la désactivation de l'encodage de sortie.

<p [innerHTML] ="htmlSnippet"></p>

Javascript - Sécurisé : interpolation angulaire

L'interpolation du texte par Angular à l'aide de doubles accolades (`{{` et `}}`) permettra au HTML d'échapper à sa sortie, le protégeant ainsi du XSS.

<p>{{HtmlSnippet}}</p>

Javascript - Non sécurisé : React DangerousInnerHTML

En spécifiant la propriété DangerouslySetInnerHTML, comme son nom l'indique, vous serez exposé au risque XSS en raison de la désactivation de l'encodage de sortie.

<div dangerouslySetInnerHTML= {{__html : htmlSnippet}} />;

Javascript - Sécurisé : React interpolé

L'interpolation du texte par React à l'aide d'accolades (`{` et `}`) permettra au HTML d'échapper à sa sortie, le protégeant ainsi du XSS.

<div>{Extrait HTML}</div>

Python - Non sécurisé : Django

Si l'on utilise le filtre « safe » dans un modèle Django, cela désactivera l'échappement automatique de la sortie et ne protégera donc pas contre le XSS.

<div>{{HtmlSnippet | sécurisé}}</div>

Python - Sécurisé : Django

L'interpolation du texte par Django à l'aide de doubles accolades (`{{` et `}}`) permettra au HTML d'échapper à sa sortie, le protégeant ainsi du XSS.

<div>{{nom}}</div>

‍