Les meilleures pratiques pour l'intégration arbitraire JSON dans les DOM?

Je suis en train de penser à propos de l'incorporation de l'arbitraire JSON dans les DOM comme ceci:

<script type="application/json" id="stuff">
    {
        "unicorns": "awesome",
        "abc": [1, 2, 3]
    }
</script>

Ceci est similaire à la façon dont on peut stocker l'arbitraire d'un modèle HTML dans les DOM pour les utiliser plus tard avec un JavaScript moteur de template. Dans ce cas, on pourrait récupérer plus tard le JSON et analyser avec:

var stuff = JSON.parse(document.getElementById('stuff').innerHTML);

Cela fonctionne, mais est-ce la meilleure solution? Est-ce à violer toutes les meilleures pratiques ou standard?

Note: je ne suis pas à la recherche de solutions pour le stockage de JSON dans les DOM, j'ai déjà décidé que c'est la meilleure solution pour le problème que je vais avoir. Je suis en quête de la meilleure façon de le faire.

  • pourquoi ne pas vous l'avoir comme var en javascript?
  • il doit faire partie d'un document statique, il est ensuite traité par une chaîne complexe de encapsulé javascript. De le ranger dans le DOM est ce que je veux faire.
  • J'étais posé avec un problème similaire. Je voulais mettre les données dans un site différent pour chaque utilisateur sans faire une requête AJAX. J'ai donc intégré du PHP dans un récipient fait quelque chose de similaire à ce que vous avez ci-dessus pour obtenir les données en javascript.
  • Je pense que votre méthode originale est le meilleur en fait. Il est 100% valide en HTML5, il est expressif, il ne veut pas créer de "faux" des éléments que vous venez de supprimer ou de masquer avec du CSS; et il ne nécessite pas de codage de caractères. Quel est l'inconvénient?
  • Si vous avez une chaîne avec la valeur </script><script>alert()</script><script> à l'intérieur de votre objet JSON, vous aurez des surprises. Ce n'est pas sûr, à moins que vous désinfecter les données de la première.
  • si j'étais à l'aveuglette remplacer tout < dans la chaîne JSON avec \u003C, serait-ce suffisant? Il semble trop simple pour vraiment travailler...

InformationsquelleAutor Ben Lee | 2012-02-16
  1. 70

    Je pense que votre méthode est la meilleure. La spec HTML5, même les adresses de cette utilisation:

    "Lorsqu'il est utilisé pour inclure des blocs de données (par opposition à des scripts), les données
    doit être incorporé en ligne, le format des données doit être donné à l'aide de
    l'attribut type de l'attribut src ne doit pas être spécifié, et le
    contenu de l'élément script doit être conforme aux exigences
    défini pour le format utilisé."

    Lire ici: http://dev.w3.org/html5/spec/Overview.html#the-script-element

    Vous avez fait exactement cela. Ce n'est pas de l'amour? Pas de codage de caractères en tant que de besoin avec les données d'attribut. Vous pouvez mettre en forme si vous le souhaitez. C'est de l'expressivité et de l'utilisation prévue est clair. Il ne se sent pas comme un hack (par exemple à l'aide de CSS pour cacher votre "transporteur" élément n'). Il est parfaitement valide.

    • Je vous remercie. La citation de la spec m'a convaincu.
    • Il est parfaitement valable uniquement si vous cochez et désinfecter l'objet JSON d'abord: vous ne pouvez pas incorporer de l'utilisateur origine des données. Voir mon commentaire sur la question.
    • extra vous demandez-vous : quel est le bon endroit pour le mettre ? la tête ou du corps, en haut ou en bas ?
    • Malheureusement, il semble que le CSP politique peut/va arrêter toutes les script balises.
    InformationsquelleAutor Jamie Treworgy
  2. 20

    Comme une direction générale, je voudrais essayer d'utiliser HTML5 attributs de données à la place. Il n'y a rien pour vous empêcher de vous mettre en JSON valide. par exemple: 

    <div id="mydiv" data-unicorns='{"unicorns":"awesome", "abc":[1,2,3]}' class="hidden"></div>

    Si vous utilisez jQuery, puis de la récupérer est aussi simple que:

    var stuff = JSON.parse($('#mydiv').attr('data-unicorns'));
    • Faire s sens. Mais notez qu'avec des guillemets simples pour le nom de la clé, JSON.parse ne fonctionne pas (au moins le natif de Google Chrome JSON.analyser ne va pas). La spécification JSON nécessite des guillemets doubles. Mais cela est assez facile à fixer à l'aide des entités telles que les ...&lt;unicorns&gt;:....
    • Une question cependant: Est-il une limite à la longueur des attributs de HTML 5?
    • Oui, cela fonctionne. Vous pouvez également basculer autour de sorte que votre HTML utilise des guillemets simples et les données JSON utilise double.
    • Ok, trouvé la réponse à ma question: stackoverflow.com/questions/1496096/... -- c'est amplement suffisant pour mes besoins.
    • Ce ne serait pas travailler pour une chaîne unique, par exemple "I am valid JSON" et en utilisant des guillemets doubles pour le tag, ou des guillemets simples avec des guillemets simples dans la chaîne, par exemple data-unicorns='"My JSON's string"' que les apostrophes ne sont pas échappé à l'encodage JSON.
    • Vous pouvez toujours utiliser escape(JSON.stringify({str: "'"}))

    InformationsquelleAutor Horatio Alderaan
  3. 11

    Cette méthode de l'intégration de json dans une balise script a un problème de sécurité potentiel. En supposant que les données json origine de la saisie de l'utilisateur, il est possible de fabriquer un membre de données qui va en effet sortir de la balise de script et de permettre l'injection directe dans les dom. Voir ici:

    http://jsfiddle.net/YmhZv/1/

    Ici est l'injection

    <script type="application/json" id="stuff">
{
    "unicorns": "awesome",
    "abc": [1, 2, 3],
    "badentry": "blah </script><div id='baddiv'>I should not exist.</div><script type="application/json" id='stuff'> ",
}
</script>

    Il n'y a juste pas moyen de contourner échapper/codage.

    • C'est vrai, mais ce n'est pas vraiment une faille de sécurité de la méthode. Si jamais vous êtes de mettre quelque chose qui a pris naissance dans la saisie de l'utilisateur dans vos pages, vous devez faire preuve de diligence au sujet de prendre la fuite. Cette méthode est encore en bon état aussi longtemps que vous prenez la normale des mesures de précaution concernant la saisie de l'utilisateur.
    • JSON n'est pas une partie de HTML, le HTML parser ne cesse de passe. C'est le même que lorsque le JSON serait une partie d'un paragraphe de texte ou de la div-élément. HTML échapper le contenu de votre programme. En outre, vous pouvez également échapper à des barres obliques. Tout en JSON ne l'exige pas, il ne tolère inutiles des barres obliques. Qui peut être utilisé à des fins de sécurité à intégrer. PHP json_encode le fait par défaut.
    InformationsquelleAutor MadCoder
  4. 5

    Je te suggère de mettre JSON dans un script en ligne avec une fonction de rappel (sorte de JSONP):

    <script>
someCallback({
    "unicorns": "awesome",
    "abc": [1, 2, 3]
});
</script>

    Si l'exécution du script est chargé après le document, vous pouvez stocker quelque part, peut-être avec un autre identificateur argument: someCallback("stuff", { ... });

    • il devrait fonctionner très bien, avec le seul inconvénient d'avoir à définir la fonction de rappel. L'autre solution proposée sauts spéciaux les caractères HTML (par exemple &) et les citations, si vous avez des personnes dans votre JSON.
    • Cela se sent mieux parce que vous n'avez pas besoin d'un dom requête pour rechercher les données
    • Je préférerais avoir un dom requête de polluer la portée mondiale...
    • Cette solution a besoin de s'échapper (juste un genre différent), voir MadCoder de réponse. Simplement laisser ici par souci d'exhaustivité.
    InformationsquelleAutor copy
  5. 5

    Voir Règle n ° 3.1 dans l'OWASP est XSS prévention de la feuille de triche.

    Dites que vous voulez inclure ce JSON en HTML:

    {
    "html": "<script>alert(\"XSS!\");</script>"
}

    Créer un caché <div> en HTML. Ensuite, sortez de vos JSON par codage dangereux entités (par exemple, &, <, >, ",", et, /) et de le mettre à l'intérieur de l'élément.

    <div id="init_data" style="display:none">
        {&#34;html&#34;:&#34;&lt;script&gt;alert(\&#34;XSS!\&#34;);&lt;/script&gt;&#34;}
</div>

    Vous pouvez maintenant accéder en lecture de la textContent de l'élément à l'aide de JavaScript et de l'analyser:

    var text = document.querySelector('#init_data').textContent;
var json = JSON.parse(text);
console.log(json); //{html: "<script>alert("XSS!");</script>"}
    • Je crois que c'est la meilleure et la plus sûre de la réponse. Notez que beaucoup de communes JSON personnages se sont échappés, et certains personnages se double d'échappement, tels que l'intérieur des guillemets dans l'objet {name: 'Dwayne "The Rock" Johnson'}. Mais il est probablement préférable d'utiliser cette approche depuis votre cadre/template library probablement déjà inclut un moyen sûr de faire le codage HTML. Une alternative serait d'utiliser base64 qui est à la fois HTML sûr et sécuritaire à l'intérieur d'un JS chaîne. Il est facile de coder/décoder en JS en utilisant btoa()/atob() et il est probablement plus facile pour vous de le faire côté serveur.
    • Encore plus sûre méthode serait d'utiliser la sémantiquement correct <data> élément et inclure les données JSON dans le value attribut. Ensuite, vous avez seulement besoin d'échapper les guillemets avec &quot si vous utilisez des guillemets pour entourer les données, ou &#39; si vous utilisez des guillemets simples (ce qui est probablement mieux).
    InformationsquelleAutor Matthew
  6. 2

    Ma recommandation serait de garder les données JSON en externe .json fichiers, et ensuite récupérer les fichiers via Ajax. Vous ne mettez pas de CSS et le code JavaScript sur la page web (inline), alors pourquoi voudriez-vous le faire avec JSON?

    • Vous ne mettez pas de CSS et de Javascript incorporé dans une page web, car il est généralement partagés entre les autres pages. Si les données en question est généré par le serveur explicitement dans ce contexte, l'intégration, il est beaucoup plus efficace que de lancer une autre demande pour quelque chose qui ne peut pas être mis en cache.
    • C'est parce que je suis en train de faire des mises à jour d'un ancien système qui a été conçu mal, et plutôt que de la refonte de l'ensemble du système, j'ai juste besoin de fixer un cadre. Le stockage de JSON dans les DOM est la meilleure façon de résoudre ce problème une partie. Aussi, je suis d'accord avec ce que @jamietre dit.
    • Notez que l'OP a déclaré que cette chaîne JSON n'est nécessaire que tard. La question est de savoir si il est nécessaire de toujours, ou seulement dans certains cas. Si il est uniquement nécessaire dans certains cas, alors il est logique d'avoir dans un fichier externe et seulement le charger de façon conditionnelle.
    • Je suis d'accord qu'il y a beaucoup de "et si ..." qui pourraient faire pencher la balance dans un sens ou l'autre. Mais de manière générale, si vous savez quand la page est rendue ce que vous allez avoir besoin, même si seulement peut - être- il est souvent préférable de l'envoyer immédiatement. Comme, si j'ai eu quelques informations boîtes de commencer collapesed, j'avais l'habitude d'inclure leur contenu en ligne, de sorte qu'elles augmentent instantanément. La surcharge d'une nouvelle demande est beaucoup par rapport à la surcharge d'un peu plus de données sur un existant, et il crée une expérience utilisateur plus réactive. Je suis sûr qu'il y est un point de rupture.
    InformationsquelleAutor Šime Vidas
  7. 0

    HTML5 comprend un <données> de l'élément pour garder des données lisibles par machine. Comme—peut-être plus sure—pour <script type="application/json"> vous pouvez inclure vos données JSON à l'intérieur de la value attribut de l'élément.

    JS:

    const jsonData = document.querySelector('.json-data');
const data = JSON.parse(jsonData.value);

console.log(data)

    HTML:

    <data class="json-data" value='
  {
    "unicorns": "awesome",
    "abc": [1, 2, 3],
    "careful": "to escape &#39; quotes"
  }
'></data>

    Dans ce cas, vous devez remplacer tous les guillemets simples avec &#39; ou avec &quot; si vous optez pour placer la valeur entre guillemets. Sinon, votre risque XSS attaques, comme les autres réponses ont suggéré.

    InformationsquelleAutor Rúnar Berg