XSS de la prévention et de la .innerHTML

Quelqu'un pourrait fournir un exemple de pourquoi je devrais codage HTML et ensuite
JS coder, et pas le double de coder en HTML lors de l'utilisation de l' .innerHTML
méthode?

Sûr.

En supposant que "l'utilisateur a fourni des données" est renseignée dans votre JavaScript par le serveur, alors vous allez avoir à coder en JS pour l'obtenir il.

Ce qui suit est de pseudo sur le serveur-côté de la fin, mais en JavaScript sur le front-end:

var userProdividedData = "<%=serverVariableSetByUser %>";
element.innerHTML = userProdividedData;

Comme ASP.NET <%= %> sorties de la variable côté serveur sans codage. Si l'utilisateur est "bon" et fournit la valeur foo, alors il en résulte dans le code JavaScript suivant en cours de rendu:

var userProdividedData = "foo";
element.innerHTML = userProdividedData;

Jusqu'à présent pas de problèmes.

Maintenant dire à un utilisateur malveillant fournit la valeur "; alert("xss attack!");//. Ce serait être traduit comme:

var userProdividedData = ""; alert("xss attack!");//";
element.innerHTML = userProdividedData;

qui entraînerait une XSS exploiter lorsque le code est exécuté dans la première ligne de la ci-dessus.

Pour éviter cela, comme vous le dites vous JS encoder. Le OWASP XSS prévention de la feuille de triche règle #3 dit:

Sauf pour les caractères alphanumériques, échapper tous les caractères de moins de
256 avec le \xHH format afin d'éviter un changement de la valeur de données
dans le contexte de script ou dans un autre attribut.

Afin de les protéger contre cette, votre code peut être

var userProdividedData = "<%=JsEncode(serverVariableSetByUser) %>";
element.innerHTML = userProdividedData;

où JsEncode encode par l'OWASP recommandation.

Cela permettrait d'éviter l'attaque ci-dessus, comme il le ferait maintenant rendu comme suit:

var userProdividedData = "\x22\x3b\x20alert\x28\x22xss\x20attack\x21\x22\x29\x3b\x2f\x2f";
element.innerHTML = userProdividedData;

Maintenant que vous avez sécurisé votre JavaScript affectation de variable contre XSS.

Cependant, si un utilisateur malveillant fourni <img src="xx" onerror="alert('xss attack')" /> que la valeur? Ce serait bien pour l'affectation de variable puisqu'elle serait tout simplement converti dans l'hexagone entité équivalente, comme ci-dessus.

Toutefois la ligne

element.innerHTML = userProdividedData;

serait la cause de alert('xss attack') être exécutée lorsque le navigateur rend l'intérieur HTML. Ce serait un DOM Basé XSS attaque.

C'est pourquoi vous avez besoin de codage HTML aussi. Ceci peut être fait via une fonction telle que:

function escapeHTML (unsafe_str) {
    return unsafe_str
      .replace(/&/g, '&')
      .replace(/</g, '&lt;')
      .replace(/>/g, '&gt;')
      .replace(/\"/g, '&quot;')
      .replace(/\'/g, '&#39;')
      .replace(/\//g, '&#x2F;')
}

rendre votre code

element.innerHTML = escapeHTML(userProdividedData);

ou pourrait être fait via JQuery text() fonction.

Mise à jour au sujet de la question dans les commentaires

J'ai juste une question: Vous avez mentionné que nous devons coder en JS
parce qu'un attaquant pourrait entrer "; alert("xss attack!");//. Mais si nous
serait d'utiliser le codage HTML au lieu de JS encodage, ne serait-ce pas aussi
HTML coder le " de signer et de faire de cette attaque impossible parce que nous
aurait: var userProdividedData =""; alert("xss
attack!");//";

Je vais prendre votre question de la manière suivante: Plutôt que de JS encodage, suivi par le codage HTML, pourquoi ne pas nous ne vous contentez pas de codage HTML, en premier lieu, et de la laisser à qui?

Bien parce qu'ils pourraient coder une attaque comme <img src="xx" onerror="alert('xss attack')" /> tous encodés à l'aide de la \xHH format pour insérer leur charge utile - ce le HTML de la séquence de l'attaque sans l'aide de l'un des personnages que le codage HTML touchera.

Il y a quelques autres attaques trop: Si l'attaquant est entré \ alors qu'ils pourraient forcer le navigateur à manquer au cours de clôture (en tant que \ est le caractère d'échappement en JavaScript).

Cela rendrait comme:

var userProdividedData = "\";

qui déclencherait une erreur JavaScript, car il n'est pas fermé correctement à l'instruction. Cela pourrait provoquer un Déni de Service à la demande s'il est rendu dans un endroit bien en vue.

En outre dire qu'il y avait deux morceaux de contrôlé par l'utilisateur de données:

var userProdividedData = "<%=serverVariableSetByUser1 %>" + ' - ' + "<%=serverVariableSetByUser2 %>";

l'utilisateur peut alors entrer \ dans la première et la ;alert('xss');// dans le second. Ce serait changer la concaténation de chaîne dans une grande affectation, suivi par une attaque XSS:

var userProdividedData = "\" + ' - ' + ";alert('xss');//";

À cause de bord de tels cas, il est recommandé de suivre l'OWASP de lignes directrices, ils sont aussi près à l'épreuve des balles que vous pouvez obtenir. Vous pourriez penser que l'ajout de \ à la liste de HTML codé valeurs résout ce, cependant, il existe d'autres raisons d'utiliser JS suivie par HTML lors du rendu du contenu de cette manière parce que cette méthode fonctionne également pour les données dans les valeurs de l'attribut:

<a href="javascript:void(0)" onclick="myFunction('<%=JsEncode(serverVariableSetByUser) %>'); return false">

Malgré si elle est simple ou double cité:

<a href='javascript:void(0)' onclick='myFunction("<%=JsEncode(serverVariableSetByUser) %>"); return false'>

Ou même non cotées:

<a href=javascript:void(0) onclick=myFunction("<%=JsEncode(serverVariableSetByUser) %>");return false;>

Si vous HTML encodé comme mentionné dans votre commentaire une entité valeur:

onclick='var userProdividedData ="";"' (version abrégée)

le code est exécuté par le navigateur de l'analyseur HTML en premier, afin de userProdividedData serait

";;

au lieu de

";

ainsi, lorsque vous l'ajouter à la innerHTML vous appeler aurait XSS de nouveau. Notez que <script> les blocs ne sont pas traitées via le navigateur de l'analyseur HTML, sauf pour la clôture de l' </script> tag, mais c'est une autre histoire.

Il est toujours sage de coder comme fin que possible comme indiqué ci-dessus. Alors si vous avez besoin à la sortie de la valeur dans un autre contexte JavaScript (par exemple, une véritable boîte d'alerte n'a pas de rendu HTML, alors il sera toujours afficher correctement).

Qui est, avec ce qui précède, je peux appeler

alert(serverVariableSetByUser);

tout aussi facilement comme paramètre HTML

element.innerHTML = escapeHTML(userProdividedData);

Dans les deux cas, il s'affiche correctement sans certains caractères de perturber le fonctionnement de la sortie ou de causer des indésirables exécution de code.

J'ai été confronté à ce problème dans ma ASP.NET Formulaires de demande. Le correctif pour ce qui est relativement simple.

Installer HtmlSanitizationLibrary de Gestionnaire de Package NuGet et consultez-le dans votre demande. Le code derrière, veuillez utiliser le désinfectant de classe de la manière suivante.

Par exemple, si le code actuel ressemble à quelque chose comme cela,

YourHtmlElement.InnerHtml = "Your HTML content" ;

Ensuite, le remplacer par le suivant:

string unsafeHtml = "Your HTML content"; 
YourHtmlElement.InnerHtml = Sanitizer.GetSafeHtml(unsafeHtml);

Ce correctif va supprimer la Veracode vulnérabilité et assurez-vous que la chaîne est rendu au format HTML. L'encodage de la chaîne au code derrière le rendre comme 'non-chaîne codée" plutôt que du HTML BRUT, comme il est codé avant le rendu commence.