XSS sans qu'un serveur soit impliqué - est-ce dangereux?

Question

Nous avons discuté d'une solution client-seule dans javascript qui fournit des moyens pour un visiteur de site pour annoter une page pour l'impression et son exploitabilité en termes de XSS ou vecteur d'attaque similaire. Justification: Il existe un processus potentiellement long qui détermine les données à afficher. Afin de documenter les mesures prises, un textarea (sans enfermer forme) est prévu que l'utilisateur peut écrire du texte arbitraire qui n'est pas censé être transféré au serveur. Le texte initial est statique, par ex. un petit jeu d'instructions sur la manière d'utiliser ce champ, de sorte qu'il n'y ait aucune possibilité (évidente) pour un attaquant de construire une URL contenant un javascript malveillant pour cette zone de texte. Une fois que les utilisateurs ont modifié ce texte, ils impriment la page (et leurs notes). Les notes sont perdues une fois que l'utilisateur quitte la page.

En cas de « trop d'erreur de prose » est ici quelques exemples de code:

<span id="descriptionHeader">Description of the result</span> 
<div id="description"> 
    <textarea id="descriptionEditor" rows="15" cols="80" type="text" 
      ondblclick="replaceDescription()"> 
Edit this text to add a detailed description to this page. 
Double click to this editing area to finish editing. 
If you want to edit the text again, do a double click to the 
description header. 
You may use html (e.g. <br>) for formatting. 
    </textarea> 
</div> 
<script type="text/javascript"> 
    var header = getElem("descriptionHeader"); 
    var editor = getElem("descriptionEditor"); 
    var description = getElem("description"); 

    function empty() { 
    } 

    function editDescription() { 
     header.ondblclick = empty; 
     editor.value = description.innerHTML; 
     description.innerHTML = ""; 
     description.appendChild(editor); 
    } 

    function replaceDescription() { 
     header.ondblclick = editDescription; 
     description.removeChild(editor); 
     description.innerHTML = editor.value; 
    } 
</script> 

Encore une fois:

• Le texte est jamais traité côté serveur, seule la description statique ("comment use ") est toujours envoyé du serveur au client, jamais du client au serveur.
• L'utilisateur peut ajouter des éléments javascript comme ils l'entendent et exploiter l'enfer hors d'eux-mêmes.
• Je ne peux pas penser à un scénario où cela pose un risque pour la sécurité, mais un sentiment reste mal au cœur ...

Note: La question ne concerne pas l'élégance de cette solution ou d'une bibliothèque qui ne montage en ligne plus confortable, mais purement sur les risques de sécurité imaginables - le cas échéant.

Answer 1

Une attaque d'ingénierie sociale est possible: Demander à un utilisateur (par chat ou autre) de copier-coller quelque chose censé être un beau modèle à ajouter à la page.

Il peut sembler moins suspect à l'utilisateur que de demander un mot de passe; mais sauf en tant qu'attaque ciblée, cela ne fonctionnera pas, car il peut être signalé assez rapidement s'il est posté sur un lieu public comme un forum. Je ne vois aucune attaque automatisée car aucune donnée ne va et vient entre le client et le serveur. Toutes les attaques sont côté client, et autres que sociaux toute attaque côté client qui pourrait modifier votre DOM ou appelez javascript sur votre page n'a pas besoin de cela pour faire XSS.

---

Notez que si nécessaire pour l'ingénierie sociale clickjacking pourrait être utilisé, en utilisant les iframes multiples sur votre site, votre site dans un iframe en dessous, un attaquant pourrait cacher le fait que la forme est celle de votre site, mais ils ont encore besoin de tromper l'utilisateur pour copier-coller le code javascript dans la zone de texte d'entrée.

---

Pour sécuriser l'entrée sans perdre la functionallity HTML, vous pouvez filtrer le code HTML par le code portage comme le stackoverflow one à javascript (Ou demander gentiment une licence pour la version javascript qui est utilisé dans l'aperçu en direct).

Answer 2

description.innerHTML = éditeur.value;

Alors qu'il est en effet relativement peu probable qu'un utilisateur pourrait être persuadé de se compromettre en tapant un est-il en fait le script <> balise, appropriée nécessaire pour leur permettre de taper HTML du tout? Que diriez-vous échapper à tout simplement la valeur:

function escapeMultiline(s) { 
    return s.split('&').join('&amp;').split('<').join('&lt;').split('\n').join('<br />'); 
}; 

description.innerHTML= escapeMultiline(editor.value); 

Ensuite, l'utilisateur peut taper joyeusement < caractères et linebreaks sans qu'ils soient mal interprétés comme HTML.

(Avec similaire de-escaping sur le chemin du retour, bien sûr.)

Answer 3

Ne connaissant pas toute l'application. Je pense qu'il serait possible d'attaquer votre système. S'ils peuvent voir d'autres pages js/autres appels valides, ils pourraient injecter ce code dans cette page pour essayer de modifier vos données dorsales. Comme dit, potentiellement en fonction de la façon dont vous avez construit votre système.

/Alberto